home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
protocol
/
gosip_v2.txt
< prev
next >
Wrap
Text File
|
1991-07-10
|
263KB
|
5,699 lines
U. S. Government Open Systems Interconnection Profile (GOSIP)
VERSION 2.0
October 1990
TABLE OF CONTENTS
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 EVOLUTION OF THE GOSIP . . . . . . . . . . . . . . . . . . . . . 1
1.4 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 APPLICABILITY . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 GOSIP VERSION 2 FUNCTIONALITY . . . . . . . . . . . . . . . . . 2
1.7 GOSIP Version 1 Errata . . . . . . . . . . . . . . . . . . . . . 3
1.8 SOURCES OF PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . . 3
1.8.1 Primary Source . . . . . . . . . . . . . . . . . . . . . . . 3
1.8.2 Secondary Sources . . . . . . . . . . . . . . . . . . . . . 3
1.8.3 Tertiary Sources . . . . . . . . . . . . . . . . . . . . . . 4
2. TESTING OF GOSIP-COMPLIANT PRODUCTS . . . . . . . . . . . . . . . . . 5
2.1 CONFORMANCE TESTING . . . . . . . . . . . . . . . . . . . . . . 5
2.2 INTEROPERABILITY TESTING . . . . . . . . . . . . . . . . . . . . 5
2.3 PERFORMANCE TESTING . . . . . . . . . . . . . . . . . . . . . . 6
2.4 FUNCTIONAL TESTING . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 VENDOR ENHANCEMENTS . . . . . . . . . . . . . . . . . . . . . . 6
3. DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS . . . . . . . . . . . . . 7
3.1 ARCHITECTURE DESCRIPTION . . . . . . . . . . . . . . . . . . . . 7
3.2 PROTOCOL DESCRIPTIONS . . . . . . . . . . . . . . . . . . . . . 10
4. PROTOCOL SPECIFICATIONS . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 USE OF THE LAYERED PROTOCOL SPECIFICATIONS . . . . . . . . . . . 12
4.1.1 Protocol Selection . . . . . . . . . . . . . . . . . . . . . 12
4.1.2 Service Interface Requirements . . . . . . . . . . . . . . . 12
4.1.3 Performance Requirements . . . . . . . . . . . . . . . . . . 13
4.2 END SYSTEM SPECIFICATION . . . . . . . . . . . . . . . . . . . . 13
4.2.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Network Layer Service . . . . . . . . . . . . . . . . . . . 14
4.2.3.1 Connectionless Mode Network Service . . . . . . . . 14
4.2.3.2 Connection-Oriented Network Service . . . . . . . . 14
4.2.3.3 Network Layer Protocol Identification . . . . . . . 15
4.2.3.4 Special Provisions For Integrated Services Digital
Networks . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Transport Layer . . . . . . . . . . . . . . . . . . . . . . 16
4.2.4.1 Connection-Oriented Transport Service . . . . . . . 16
i
4.2.4.2 Connectionless Mode Transport Service . . . . . . . 16
4.2.5 Session Layer . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.6 Presentation Layer . . . . . . . . . . . . . . . . . . . . . 17
4.2.7 Application Layer . . . . . . . . . . . . . . . . . . . . . 17
4.2.7.1 Association Control Service Elements . . . . . . . . 17
4.2.7.2 File Transfer, Access, and Management Protocol (FTAM) 17
4.2.7.3 Message Handling Systems . . . . . . . . . . . . . . 17
4.2.7.4 Virtual Terminal (VT) Basic Class . . . . . . . . . 18
4.2.8 Exchange Formats . . . . . . . . . . . . . . . . . . . . . . 18
4.2.8.1 Office Document Architecture (ODA) . . . . . . . . . 18
4.3 INTERMEDIATE SYSTEM SPECIFICATION . . . . . . . . . . . . . . . 19
5. ADDRESSING REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 NETWORK LAYER ADDRESSING AND ROUTING . . . . . . . . . . . . . . 20
5.1.1 NSAP Address Administration, Routing Structures and NSAP
Address Structure . . . . . . . . . . . . . . . . . . . . . . 20
5.1.2 NSAP Address Registration Authorities . . . . . . . . . . . 22
5.1.2.1 Responsibilities Delegated by NIST . . . . . . . . . 22
5.1.3 GOSIP Routing Procedures . . . . . . . . . . . . . . . . . . 23
5.2 UPPER LAYERS ADDRESSING . . . . . . . . . . . . . . . . . . . . 23
5.2.1 Address Structure . . . . . . . . . . . . . . . . . . . . . 23
5.2.2 Address Assignments . . . . . . . . . . . . . . . . . . . . 24
5.2.3 Address Registration . . . . . . . . . . . . . . . . . . . . 24
5.3 IDENTIFYING APPLICATIONS . . . . . . . . . . . . . . . . . . . . 24
5.3.1 FTAM and File Transfer User Interface Identification . . . . 24
5.3.2 MHS and Message User Interface Identification . . . . . . . 24
6. SECURITY OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1 REASON FOR DISCARD PARAMETERS . . . . . . . . . . . . . . . . . 26
6.2 SECURITY PARAMETER FORMAT . . . . . . . . . . . . . . . . . . . 27
6.2.1 Parameter Code . . . . . . . . . . . . . . . . . . . . . . . 27
6.2.2 Parameter Length . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3 Parameter Value . . . . . . . . . . . . . . . . . . . . . . 27
6.2.3.1 Security Format Code . . . . . . . . . . . . . . . . 28
6.2.3.2 Basic Portion . . . . . . . . . . . . . . . . . . . 28
6.2.3.3 Extended Portion . . . . . . . . . . . . . . . . . . 28
6.3 BASIC PORTION OF THE SECURITY OPTION . . . . . . . . . . . . . . 28
6.3.1 Basic Type Indicator . . . . . . . . . . . . . . . . . . . . 28
6.3.2 Length of Basic Information . . . . . . . . . . . . . . . . 29
6.3.3 Basic Information . . . . . . . . . . . . . . . . . . . . . 29
6.3.3.1 Classification Level . . . . . . . . . . . . . . . . 29
6.3.3.2 Protection Authority Flags . . . . . . . . . . . . . 29
6.4 EXTENDED PORTION OF THE SECURITY OPTION . . . . . . . . . . . . 30
6.4.1 Extended Type Indicator . . . . . . . . . . . . . . . . . . 31
6.4.2 Length of Extended Information . . . . . . . . . . . . . . . 31
6.4.3 Extended Information . . . . . . . . . . . . . . . . . . . . 31
6.4.3.1 Additional Security Information Format Code . . . . 32
6.4.3.2 Length of Additional Security Information . . . . . 32
6.4.3.3 Additional Security Information . . . . . . . . . . 32
6.5 USAGE GUIDELINES . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.1 Basic Portion of the Security Option . . . . . . . . . . . . 33
6.5.2 Extended Portion of the Security Option . . . . . . . . . . 33
ii
6.6 OUT-OF-RANGE PROCEDURE . . . . . . . . . . . . . . . . . . . . . 33
6.7 TRUSTED INTERMEDIARY PROCEDURE . . . . . . . . . . . . . . . . . 34
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
iii
APPENDICES
FOREWORD TO THE APPENDICES . . . . . . . . . . . . . . . . . . . . . . . 41
APPENDIX 1. SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . 42
APPENDIX 2. SYSTEM AND ARCHITECTURE . . . . . . . . . . . . . . . . . . 46
APPENDIX 3. UPPER LAYERS . . . . . . . . . . . . . . . . . . . . . . . 50
APPENDIX 4. EXCHANGE FORMATS . . . . . . . . . . . . . . . . . . . . . . 56
APPENDIX 5. LOWER LAYER PROTOCOLS . . . . . . . . . . . . . . . . . . . 59
APPENDIX 6. ACRONYMS . . . . . . . . . . . . . . . . . . . . . . . . . . 62
iv
LIST OF FIGURES
Figure 3.1 GOSIP Version 1 OSI Architecture . . . . . . . . . . . . . . 8
Figure 3.2 GOSIP Version 2 OSI Architecture . . . . . . . . . . . . . . 9
Figure 5.1.1 NSAP Address Structure . . . . . . . . . . . . . . . . . . 20
Figure 5.1.2 The NIST ICD Addressing Domain . . . . . . . . . . . . . . 21
Figure 5.1.3 GOSIP NSAP Address Structure . . . . . . . . . . . . . . . 21
Figure 5.2.1 Upper Layers Address Structure . . . . . . . . . . . . . . 24
Figure A.1 Framework for OSI Security . . . . . . . . . . . . . . . . . 45
v
LIST OF TABLES
Table 5.3 Required O/R Name Attributes . . . . . . . . . . . . . . . . . 25
Table 6.1 Extended Values in the Reason For Discard Parameter . . . . . 26
Table 6.2 Security Parameter Format . . . . . . . . . . . . . . . . . . 27
Table 6.3 Format - Parameter Value Field . . . . . . . . . . . . . . . . 27
Table 6.4 Format - Basic Portion . . . . . . . . . . . . . . . . . . . . 28
Table 6.5 Format - Basic Information Field . . . . . . . . . . . . . . . 29
Table 6.6 Classification Levels . . . . . . . . . . . . . . . . . . . . 29
Table 6.7 Protection Authority Bit Assignments . . . . . . . . . . . . . 30
Table 6.8 Format - Extended Portion . . . . . . . . . . . . . . . . . . 31
Table 6.9 Format - Extended Information Field . . . . . . . . . . . . . 32
vi
FOREWORD
The U.S. Government Open Systems Interconnection (OSI) Advanced Requirements
Group was established by the National Institute of Standards and Technology
(NIST) in cooperation with the Information Resource Managers of the Federal
agencies. The group's purpose is to coordinate the acquisition and operation
of OSI products by the Federal government. This document specifies the U. S.
Government OSI profile. A profile is a cross-section of functional
applications pertaining to a particular environment.
It is expected that the Administrator of the General Services Administration
(GSA) will provide for the implementation of Open Systems Interconnection
(OSI) according to this profile.
The National Institute of Standards and Technology (NIST) will issue this
profile as a Federal Information Processing Standard (FIPS). This is Version
2 of the Government Open Systems Interconnection Profile. It contains an
updated specification of the OSI protocols that meet government needs.
Products based on these protocols are or soon will be available from major
vendors.
Organizations contributing to the development of this profile are given below.
Department of Agriculture
Department of Commerce
Department of Defense
Department of Energy
Department of Education
Department of Health and Human Services
Department of Housing and Urban Development
Department of the Interior
Department of Justice
Department of Labor
Department of Transportation
Department of the Treasury
Environmental Protection Agency
General Services Administration
Library of Congress
National Aeronautics and Space Administration
National Communications System
National Science Foundation
Office of Management and Budget
Veterans Administration
vii
PREFACE
This is a Federal Government procurement profile for open systems computer
network products. Section 1 contains introductory material, the purpose and
scope of the profile, and the sources of the protocol specifications contained
in the profile. Section 2 contains general statements on conformance,
interoperation and performance of network systems covered by this profile.
Section 3 contains a brief description of the OSI architecture and protocols
that apply to this profile. The network protocols are specified in section 4,
the principal part of this profile. Accompanying each protocol implementation
reference is a statement of conformance identifying the required functional
units of that protocol. section 5, Addressing Requirements, is also an
integral and mandatory part of this profile. Technical Support Personnel to
Acquisition Authorities must be familiar with the terminology and ideas
expressed in sections 4 and 5.
Section 6 defines security options that, if needed, must be explicitly
requested in Requests For Proposals.
This profile will change with improvements in technology and with the
evolution of network protocol standards. Appendices specify future work items
needed to enrich the profile, and thus, improve its utility to the agencies.
viii
GLOSSARY
The terms defined below are used frequently throughout this profile. They are
defined here to aid the lay reader. Other terms appearing in sections 4 and 5
are defined in Federal Standard 1037A and ISO 7498 and must be thoroughly
understood by the Technical Support Personnel to Acquisition Authorities.
Protocol
In the Open Systems Interconnection reference model, the communication
functions are partitioned into seven layers. Each layer, N, provides a
service to the layer above, N+1, by carrying on a conversation with layer N on
another processor. The rules and conventions of that N-layer conversation are
called a protocol.
End System
An end system (ES) contains the application processes that are the ultimate
sources and destinations of user oriented message flows. The functions of an
end system can be distributed among more than one processor/computer.
Intermediate System
An intermediate system (IS) interconnects two or more subnetworks. For
example, it might connect a local area network with a wide area network. It
performs routing and relaying of traffic. A processor can implement the
functions of both an end system and an intermediate system.
A system implementing all seven layers of protocol may provide service
directly to users (acting as an end system), and it may connect subnetworks
(acting as an intermediate system). When it performs the functions of an
intermediate system, only the lower three layers of protocol are exercised.
Open System
An open system is a system capable of communicating with other open systems by
virtue of implementing common international standard protocols. End systems
and intermediate systems are open systems. However, an open system may not be
accessible by all other open systems. This isolation may be provided by
physical separation or by technical capabilities based upon computer and
communications security.
Federal Government Terminology
The following definitions are informal and generic and are provided for the
benefit of private sector organizations that review the profile. Agency
regulations and any contract should be referred to for precise terms and their
usage. Also, other terms may be used in lieu of these in agency regulations
and in specific contracts.
Acquisition Authority
ix
An Acquisition Authority, commonly known as a contracting officer, is an
individual who, under Federal law and acquisition regulations, has the
authority to enter into, administer, and/or terminate a government contract.
Federal Acquisition Regulation (FAR)
The FAR is applicable to Executive departments and agencies of the Federal
Government in the area of acquisition, leasing, and rental of personal
property and services. Many departments and agencies have supplementary
regulations that apply to their acquisitions.
Federal Information Resources Management Regulation (FIRMR)
The FIRMR is applicable to federal departments and agencies in the areas of
management, acquisition and use of information resources, including automatic
data processing and telecommunications equipment and services.
Requests For Proposals (RFP)
Requests For Proposals are documents issued by the government to request bids
for products or services.
x
1. INTRODUCTION
1.1 BACKGROUND
Both the government and the private sector recognize the need to develop a set
of common data communication protocols based on the International Organization
for Standardization's seven-layer Open Systems Interconnection (OSI) Basic
Reference Model [ISO 1]. In the past, vendor-specific implementations of data
communication protocols led to isolated domains of information, very difficult
and expensive to bridge. Recent advances in communication technology based on
the OSI model offer alternatives to vendor-specific network solutions. Most
significantly, advances in open systems allow the interoperation of end
systems of different manufacture, when required.
This Government Open Systems Interconnection Profile (GOSIP) is based on
agreements reached at the National Institute of Standards and Technology
(NIST) Workshop for Implementors of Open Systems Interconnection. Each new
version of GOSIP will reference the latest appropriate version of the Stable
Implementation Agreements for Open Systems Interconnection Protocols [NIST 1],
hereafter referred to as the Workshop Agreements. The Workshop Agreements
record stable implementation agreements of OSI protocols among the
organizations participating in the NIST Workshop for Implementors of OSI.
A new version of the Workshop Agreements is created each year at the December
OSI Implementors' Workshop meeting. It is the intent of the NIST Workshop
that new versions of the Workshop Agreements will be backwardly compatible
with previous versions. New editions of the same version of the Workshop
Agreements are published at regular intervals during the year. These new
editions contain errata and clarifications to the original agreements that are
approved by the Workshop plenary. The latest editions are being distributed
to all workshop attendees and are available through the National Technical
Information Service (NTIS). See NIST Reference 1 for ordering information.
GOSIP is also consistent with and complementary to industry's Manufacturing
Automation Protocol (MAP) [MISC 1] and Technical and Office Protocols (TOP)
[MISC 2] specifications. GOSIP addresses the need of the Federal Government
to move immediately to multi-vendor interconnectivity without sacrificing
essential functionality already implemented in critical networking systems.
All capabilities described herein exist as standard products or are close
enough to market that they can be proposed by vendors.
1.2 PURPOSE
This profile is the standard reference for all federal government agencies to
use when acquiring and operating ADP systems or services and communication
systems or services intended to conform to ISO Open Systems Interconnection
protocols which provide interoperability in a heterogeneous environment.
1.3 EVOLUTION OF THE GOSIP
The GOSIP FIPS will be updated by issuing new versions at appropriate
intervals to reflect the progress being made by vendors in providing OSI
1
products with new services useful to Federal agencies. A new version of GOSIP
will supersede the previous version of the document because it will include
all of the protocols in the previous version plus additional new protocols.
Procurement of the new protocols is mandated in Federal procurement requests
initiated eighteen months after the version of GOSIP containing those
protocols is promulgated as a FIPS. Every new version of GOSIP will specify
the architecture and protocols that were included in each of the previous
versions so that Federal agencies can easily determine the applicable
compliance date for each protocol.
It is a goal that a new version of GOSIP will be upwardly compatible with the
previous versions. However, changes may be required to correct errors and to
align with activity in the international standards organizations. Any errata
required to a previous version of GOSIP will be identified in the new GOSIP
version. Unless otherwise stated, the mandatory compliance date of the
previous version of GOSIP also
applies to the errata. These errata will not be included without ensuring that
they have the strong support of the vendors who are providing OSI products so
that users can be confident that these changes will not inhibit
interoperability. See section 1.7 for the GOSIP Version 1 errata.
1.4 SCOPE
In an increasingly complex world, the need to exchange information has become
an ever more important factor in conducting business. Federal agencies need
to share information not only with other Federal agencies, but with state and
local governments and commercial organizations as well. Until recently,
computer networking technology has not kept pace with this need to
communicate. Even now, many Federal agencies have "islands" of computer
systems built by different vendors, or by the same vendor, that cannot
interoperate.
The GOSIP, in addition to being a Federal mandate, is an alert that the vendor
community has developed a nonproprietary solution for this requirement to
exchange information. The solution is the OSI protocols upon which GOSIP is
based. Version 1 of GOSIP (FIPS 146) provided electronic mail and file
transfer services using the OSI standards for Message Handling Systems (MHS)
and File Transfer, Access, and Management (FTAM). Version 1 of GOSIP provided
interoperability among users on X.25, 802.3, 802.4, and 802.5 subnetworks. In
addition, Version 1 of GOSIP created a foundation upon which to build new
protocols providing new services useful to Federal agencies.
Version 2 of GOSIP (FIPS 146-1) uses that foundation to provide a remote
terminal access capability using the Virtual Terminal (VT) standard. At the
network layer, Version 2 of GOSIP extends interoperabity to include ISDN
subnetworks. Future versions of GOSIP will add new user services such as
Directory Services, Transaction Processing, Electronic Data Interchange and
Remote Data Base Access as well as allow interoperability among users served
by other network technologies.
GOSIP does not mandate that government agencies abandon their favorite
2
computer networking products. GOSIP does mandate that government agencies,
when acquiring computer networking products, purchase OSI capabilities in
addition to any other requirements, so that multi-vendor interoperability
becomes a built-in feature of the government computing environment, a fact of
life in conducting government business.
The OSI protocols have the potential to change the way the Federal Government
does business. It is essential that Federal agencies make a strategic
investment in OSI beginning now, so that they will be well positioned to take
advantage of the new services provided by the OSI protocols as they become
available. Planning the integration of OSI may require considerable time and
effort, but this work will be more than offset by the benefits provided by the
new technology.
1.5 APPLICABILITY
GOSIP specifies a set of OSI protocols for computer networking that is
intended for acquisition and use by government agencies. It must be used by
all Federal government agencies when acquiring products and services which
provide equivalent functionality to the OSI protocols referenced in this
document. For a more detailed statement of applicability, see FIPS 146.
1.6 GOSIP VERSION 2 FUNCTIONALITY
Version 2 of GOSIP contains the following functionality not included in
Version 1.
1. The Virtual Terminal Service (TELNET and Forms profiles);
2. The Office Document Architecture (ODA);
3. The Integrated Services Digital Network (ISDN);
4. The End System-Intermediate System protocol (ES-IS), and as user
options;
5. The Connectionless Transport Service (CLTS); and,
6. The Connection-Oriented Network Service (CONS).
The compliance information for GOSIP Version 2 functions is stated in the FIPS
announcement. Since the Connectionless Transport Service and the Connection-
Oriented Network Service are provided as optional user services, there is no
mandatory compliance specified. All GOSIP protocols not included in the above
list are bound by the GOSIP Version 1 compliance date which is August 15,
1990. Figure 3.1 illustrates the GOSIP Version 1 architecture and protocols.
Figure 3.2 illustrates the GOSIP Version 2 architecture and protocols.
1.7 GOSIP Version 1 Errata
1. Since Version 1 of the Stable Implementation Agreements for OSI
Protocols was published, errata have been added to those agreements, primarily
by the FTAM and Upper Layer Special Interest Groups (SIGs) of the NIST OSI
Implementors' Workshop to correct problems in the original agreements and to
align with agreements being developed internationally. Version 1 of GOSIP
will now reference the relevant sections of Version 3 of the Stable
Implementation Agreements. Text for these sections is available from the
3
Government Printing Office and NTIS.
2. Version 1 of GOSIP (section 5.3.2) required that private messaging
systems within the government be capable of routing on administration name,
private domain name, organization name, organization unit and personal name.
The requirement that private messaging systems be capable of routing based on
personal name has been deleted. This change expands the range of messaging
systems that are GOSIP compliant.
3. GOSIP Version 1 implementations should use the Network Service Access
Point (NSAP) Address structure in Figure 5.1.3 of GOSIP Version 2. This
change was made to align with the routing standards currently being developed
by the ISO.
4. Version 1 of GOSIP (section 4.2.3) required that processing of
Protocol Data Units by the Connectionless Network Layer Protocol be in order
of priority. This requirement has been deleted.
5. Version 1 of GOSIP describes a general architecture for OSI security,
defines a set of optional security services that may be supported within the
OSI model, and outlines a number of mechanisms that can be used in providing
the service. Users should now refer to the updated Security Options section
in Version 2 of GOSIP. It should be noted that, even in Version 2 of GOSIP,
the security section is optional and is considered a placeholder for future
security specifications.
1.8 SOURCES OF PROTOCOL SPECIFICATIONS
1.8.1 Primary Source
The primary source of protocol specifications in GOSIP is the Stable
Implementation Agreements for Open Systems Interconnection Protocols [NIST 1].
This source document was created and is maintained by the NIST Workshop for
Implementors of Open Systems Interconnection. It provides implementation
specifications that are derived from service and protocol standards issued by
the International Organization for Standardization (ISO), the Consultative
Committee for International Telegraphy and Telephony (CCITT), and the
Institute of Electrical and Electronics Engineers, Inc. (IEEE).
By primary source, it is meant that where GOSIP uses a given protocol, it
cites that protocol by reference as specified in the above-named Workshop
Agreements. The primary source is used in all instances where the protocol of
interest has been specified in the Workshop Agreements. Section 4 of this
profile gives conformance statements for each protocol that, in some cases,
are augmented from the minimal conformance statements in the Workshop
Agreements in order to provide the functionality required for government
computer networking.
1.8.2 Secondary Sources
GOSIP must be complete in that open systems procured in accordance with it
must interoperate and must provide service generally useful for government
4
computer networking applications. The Workshop Agreements continue to evolve,
but they are still incomplete. (The appendices of GOSIP cite needed work.)
Thus, where the Workshop Agreements do not provide completeness, GOSIP may
augment protocol and service specifications from the following sources, listed
in precedence order.
o International Standards and Recommendations
o Draft International Standards
Since this profile is one of open systems, the secondary sources include
specifications that are international standards or are advancing to become
international standards. They are included in GOSIP, where needed, to help
satisfy the criterion of completeness, and thus, utility. Note that secondary
sources exclude protocols, however mature, that are not a part of the
international standards process.
1.8.3 Tertiary Sources
Even the secondary sources named above may not provide a complete and useful
networking system today. It may be necessary for GOSIP to augment protocol
and service specifications from the following sources, listed in precedence
order.
o ANSI Standards
o Draft Proposed International Standards
o Federal Information Processing Standards
o Military Standards
For example, security protocols might be incorporated from a FIPS issued by
NIST. The use of protocols from other than the primary and secondary sources
is undesirable. It is expressly intended that these omissions from standards
work be brought to the attention of the international standards bodies so that
acceptable international standards may be developed as rapidly as possible.
The GOSIP Advanced Requirements Group will replace all tertiary source
protocols in GOSIP with suitable primary and secondary source substitutes,
when available.
5
2. TESTING OF GOSIP-COMPLIANT PRODUCTS
Conformance testing verifies that an implementation acts in accordance with a
particular specification, such as GOSIP. Interoperability testing duplicates
the "real-life" environment in which an implementation will be used.
Performance testing measures whether an implementation satisfies the
performance criteria of the user. Functional testing determines the extent to
which an implementation meets user functional requirements.
NIST issued GOSIP Version 1.0 testing guidance in GOSIP Conformance and
Interoperation Testing and Registration [NIST 8]. Consult that reference for
detailed procedures, instructions for GOSIP product suppliers, and
recommendations for Acquisition Authorities. A future revision to GOSIP
Conformance and Interoperation Testing and Registration will add procedures,
instructions, and recommendations for the new protocols included in GOSIP
Version 2.0. Until such revision occurs, Federal agency personnel should use,
for testing GOSIP Version 2.0 additions, the interim guidance supplied below
in sections 2.1 and 2.2.
NIST issued Message Handling Systems Evaluation Guidelines [NIST 9] to assist
Federal agency personnel to evaluate the degree to which specific Message
Handling Systems products meet the specific performance and functional
requirements of an agency procurement. Further guidelines are planned; File
Transfer, Access and Management will be the next. If a guideline is not yet
available for an application of interest, Federal agency personnel should use
the interim guidance supplied in sections 2.3, 2.4, and 2.5.
2.1 CONFORMANCE TESTING
Conformance is shown by the vendor having passed conformance tests adequate
for the purpose of exercising the functional units specified in section 4.
Conformance to the GOSIP will only apply to the profile defined by the
Acquisition Authority. For the purposes of testing conformance to the
protocols required by GOSIP Version 2.0, the Acquisition Authority will
provide documentation which identifies specific testing requirements.
Conformance tests and test systems are currently being developed by several
testing organizations. When these test systems for GOSIP Version 2.0 are
completed, NIST will specify the tests, test systems and testing organizations
that are accredited to perform conformance testing of GOSIP protocols.
For the interim, the Acquisition Authority shall require that vendors
substantiate any claim of GOSIP conformance.
The Acquisition Authority shall also be responsible for determining that
acceptable test results are available as a prerequisite to awarding of a final
procurement contract.
2.2 INTEROPERABILITY TESTING
The Acquisition Authority should specify a detailed set of requirements that
6
will serve to test interoperability of GOSIP Version 2.0 protocols. The
Acquisition Authority must specify the following for this testing:
- the products to be used for the interoperability testing,
including hardware and software versions and components,
- a detailed description of planned test scenarios to be run between
implementations in the interoperability testing, including the
results expected, and
- criteria for passing or failing the testing.
NIST will recommend vehicles particularly suitable for interoperability
testing.
2.3 PERFORMANCE TESTING
The principal thrust of OSI is to provide interworking of distributed
applications using heterogeneous, multi-vendor systems. GOSIP does not cite
performance criteria. Note that protocol definitions include quality of
service parameters and other tunable functions. The Acquisition Authority
must determine and specify those performance related features that are desired
to be under user or application process control and those desired to be under
system operator control. The Acquisition Authority may also wish to specify
benchmarking criteria as evidence of satisfying performance requirements.
2.4 FUNCTIONAL TESTING
The GOSIP specification mandates for each protocol a minimum set of functions
to meet general government requirements. In many instances additional
functions might be supported within the Workshop Agreements and/or the
protocol standard. The Acquisition Authority must determine and specify such
additional functions that are required within an acquisition. The Acquisition
Authority is responsible for determining that the vendor products proposed
meet any and all functional requirements.
2.5 VENDOR ENHANCEMENTS
It is expected that most vendors will update their products, for example, from
a Draft International Standard version to an International Standard version,
as implementation specifications are completed in the Workshop Agreements.
Also, some vendors may provide additional functionality. Implementations that
go beyond the functional units stated in section 4 must be implemented
according to the Workshop Agreements and must interwork with implementations
that strictly comply with section 4. Requests For Proposals should encourage
vendor enhancements where required to meet user needs.
7
3. DESCRIPTIONS OF ARCHITECTURE AND PROTOCOLS
This section briefly describes the GOSIP architecture and protocols. For a
more thorough understanding, consult the Government Open Systems
Interconnection User's Guide [NIST 7] and other references cited in this
profile.
3.1 ARCHITECTURE DESCRIPTION
Figure 3.1 illustrates the GOSIP Version 1 architecture and protocols. Figure
3.2 shows how new protocols providing new services have been added to GOSIP
Version 2 while maintaining compatibility with GOSIP Version 1.
Achieving OSI within the government is best accomplished by using a single
method (one protocol profile at each OSI layer) to perform the functions of
routing and reliable data transfer. Fig. 3.2 shows that these functions are
provided by the transport class 4, and connectionless network layer protocols.
Mandatory use of a single transport protocol class (class 4) and a
connectionless network layer protocol (CLNP) assures interoperable data
transfer between government computer systems for a variety of applications
across a variety of subnetwork technologies. Optional use of additional
transport and network layer protocols is not precluded by GOSIP; in fact, as
shown in Figure 3.2, GOSIP now includes specifications for an optional
connectionless transport service and an optional connection-oriented network
service. The specifications give sufficient detail for achieving interworking
among government computer systems implementing these options.
It is useful to enable user selection from among a set of lower layer
subnetwork technologies for local and wide area networking. These different
technologies exhibit physical, performance, and cost differences that render
one technology more appropriate than others for particular uses. Fig. 3.2
illustrates six subnetwork technologies specified by GOSIP. These are the
packet data network (X.25), the point to point (Pt-Pt) LAP B Subnetwork, the
Integrated Services Digital Network (ISDN), the Token Bus (ISO 8802/4), the
Token Ring (ISO 8802/5) and the Carrier Sense Multiple Access with Collision
Detection (ISO 8802/3). When a point to point or local area subnetwork
technology is selected, the CLNP end system to intermediate system (CLNP ES-
IS) routing protocol [ISO 44] is also required. Other lower layer subnetwork
technologies may be used, but the Acquisition Authority must provide proper
specification to ensure procurement of an effective product, that is, a
product able to support operation of transport class 4, the connectionless
network protocol, and the GOSIP upper layer protocols.
Interconnection of multiple wide-area networks to form the appearance of a
single logical wide-area network may be accomplished by any technically
appropriate means such as X.75 gateways. Interconnection of remote local area
networks to form the appearance of a single logical network may be
accomplished by any technically appropriate means, such as MAC bridges. In
all other instances, the GOSIP mandates subnetwork interconnection by means of
the CLNP and the network access methods appropriate for the specific networks
being interconnected.
8
At the application layer, many protocols are expected to be included in GOSIP
over time, each applying to different uses. In Fig. 3.2, the current
application protocols are File Transfer, Access and Management (FTAM) based on
the ISO International Standard [ISO 16-19], the Basic Class Virtual Terminal
Protocol based on the ISO International Standard [ISO 32-35], and Message
Handling Systems based on the 1984 CCITT Recommendations [CCITT 2-9]. Each
application may require a different selected set of services from the
application control service elements and the presentation and session control
layers. Thus, layers 5, 6, and 7 may be thought of as an integral package of
GOSIP upper layer protocols for each specific application.
9
Figure 3.1 GOSIP Version 1 OSI Architecture
10
Figure 3.2 GOSIP Version 2 OSI Architecture
11
The Office Document Architecture (ODA) standard based on the ISO International
Standards [ISO 36-42, CCITT 17-24] is also included in GOSIP. Although ODA is
not an OSI protocol, it is included in GOSIP because it provides services
required by Federal agencies, and the information specified by the standards
can be transported by the OSI FTAM and MHS Application layer protocols.
A goal of this profile is to permit an Acquisition Authority to issue
unambiguous procurement requests for standard applications operating over
networks using standard protocols. The Acquisition Authority determines the
required applications and the required networks and the GOSIP defines the
required protocols. For example, if an Acquisition Authority requires a
general purpose File Transfer Access and Management application on a CSMA/CD
subnetwork, the GOSIP defines that layer 7 FTAM is required along with certain
services from the application control service elements, presentation, and
session protocols. To perform the data transfer function, GOSIP mandates the
Class 4 transport protocol and the connectionless network layer protocol, and
defines a subset of the ISO 8802/2 link layer, and the ISO 8802/3 CSMA/CD
protocol.
3.2 PROTOCOL DESCRIPTIONS
Following are brief narratives of the general services provided by protocols
in each layer of the GOSIP architecture to the layer above.
The Application layer (layer 7) allows for protocols and services required by
particular user-designed application processes. Functions satisfying
particular user requirements are contained in this layer. Representation and
transfer of information necessary to communicate between applications are the
responsibility of the lower layers. See References [NIST 1; ISO 1, 16-19, 22-
25, 32-35; CCITT 2-9, 14].
The Presentation layer (layer 6) specifies or, optionally, negotiates the way
information is represented for exchange by application entities. The
presentation layer provides the representation of: 1) data transferred between
application entities, 2) the data structure that the application entities use,
and 3) operations on the data's structure. The presentation layer is
concerned only with the syntax of the transferred data. The data's meaning is
known only to the application entities, and not to the presentation layer.
See References [NIST 1; ISO 1,20,21,24,25].
The Session layer (layer 5) allows cooperating application entities to
organize and synchronize conversation and to manage data exchange. To
transfer the data, session connections use transport connections. During a
session, session services are used by application entities to regulate
dialogue by ensuring an orderly message exchange on the session connection.
See References [NIST 1; ISO 1,14,15; CCITT 12,13].
The Transport layer (layer 4) connection-oriented service provides reliable,
transparent transfer of data between cooperating session entities. The
transport layer entities optimize the available network services to provide
the performance required by each session entity. Optimization is constrained
by the overall demands of concurrent session entities and by the quality and
12
capacity of the network services available to the transport layer entities.
In the connection-oriented transport service, transport connections have end-
to-end significance, where the ends are defined as corresponding session
entities in communicating end systems. Connection-oriented transport
protocols regulate flow, detect and correct errors, and multiplex data, on an
end-to-end basis. See References [NIST 1; ISO 1,12,13; CCITT 10,11]. The
transport layer also supports a simple connectionless transport service [ISO
46-47].
The Network layer (layer 3) provides message routing and relaying between end
systems on the same network or on interconnected networks, independent of the
transport protocol used. The network layer may also provide hop-by-hop
network service enhancements, flow control, and load leveling. Services
provided by the network layer are independent of the distance separating
interconnected networks. See References [NIST 1,3; ISO 1-8,11; CCITT 1; NCS
1].
The Data link layer (layer 2) provides communication between two or more
(multicast service) adjacent systems. The data link layer performs frame
formatting, error checking, addressing, and other functions necessary to
ensure accurate data transmission between adjacent systems. Note that the
data link layer can operate in conjunction with several different access
methods in the physical layer. See Figure 3.2 for examples. See References
[NIST 1-3,5; ISO 1,26,28; CCITT 1].
The Physical layer (layer 1) provides a physical connection for transmission
of data between data link entities. Physical layer entities perform
electrical encoding and decoding of the data for transmission over a medium
and regulate access to the physical network. See References [NIST 1-3; ISO 1;
ISO 29-31; IEEE 1].
13
4. PROTOCOL SPECIFICATIONS
4.1 USE OF THE LAYERED PROTOCOL SPECIFICATIONS
The individual protocol and interface specifications in this section shall be
used directly in Requests For Proposals. However, Acquisition Authorities
must take additional steps to ensure an adequate specification for their
intended purpose. The following items must be supplied by the Acquisition
Authority.
4.1.1 Protocol Selection
The architecture described in section 3 suggests a range of protocol choices
at different layers of the OSI Reference Model. A subset of these protocols
may adequately satisfy an individual acquisition requirement, and may be used.
If a subset of the protocols and interface profiles is chosen, it is the
Acquisition Authority's responsibility to ensure that all paths through the
architecture are complete, i.e., (1) that protocols from layer 1 through layer
7 are included for end systems and at least layers 1 through 3 are included
for intermediate systems, and (2) that the appropriate service interface
specifications for the selected protocols are also included, as indicated in
section 4.1.2 below.
With respect to selecting protocols, at least one lower layer technology must
be chosen, i.e., CSMA/CD (carrier sense, multiple access with collision
detection) [NIST 1, 2; ISO 28, 29], Token Bus [NIST 1; ISO 28, 30], Token
Ring [NIST 1; ISO 28, 31]; X.25 [NIST 1, 3; CCITT 1; ISO 8]; HDLC LAP B point
to point (Pt-Pt) subnetwork [ISO 26] or ISDN [NIST 1, ANSI 1-3, CCITT 25-27,
ISO 45]. Additional lower layer technologies may be used to meet special
requirements. The following protocol layers are mandatory for compliance with
GOSIP: the connectionless network layer protocol, transport class 4, and
session. Transport class 0 and the Connection Oriented Network Service (CONS)
[ISO 2,3] are mandated only in conjunction with public data network messaging;
see section 4.2.7.3, Message Handling Systems. Presentation protocol and
association control service elements are required for all applications except
messaging. At least one application layer specific protocol is required to
support the intended application. For example, if messaging is required,
specify MHS; if file transfer is required, specify FTAM; and, if the Virtual
Terminal Service is required, specify VT. The provision of the CONS, for
general use, and the Connectionless Transport Protocol (CLTP) are options that
may be specified in addition to the GOSIP mandatory Connectionless Network
Service (CLNS) and Transport (class 4), respectively. More detailed
specification guidance is provided in sections 4.2 and 4.3.
4.1.2 Service Interface Requirements
GOSIP mandates no service interface accessibility beyond that indicated in the
Workshop Agreements; therefore, any additional service interface accessibility
requirements must be clearly stated and mandated by the Acquisition Authority.
For example, GOSIP mandates no specific direct access to transport services.
If the Acquisition Authority requires direct access to transport services,
14
such a requirement must be included in a solicitation. The issues involved in
determining such a requirement are complex. Refer to the GOSIP Users' Guide
for a discussion of these issues.
Should the Acquisition Authority not request direct access to service
interfaces, such access might or might not be provided at the discretion of
individual vendors. For example, some vendors may provide access to session
services, others may provide access to transport and network services, and
still others may limit access to association control services only. Of
course, some vendors may provide direct access to service interfaces at the
human user interface only. When there is no requirement for a service
interface between layers, vendors might merge multiple layer implementations.
Such a merger is often implemented to accrue performance benefits to the user.
Should the Acquisition Authority request direct access to a specific service
interface, care should be taken to specify the general functional and
operational objectives of the interface; otherwise, particular vendor
interface implementations might or might not meet user requirements. While
specifying the general functional and operational objectives for a service
interface should enable the vendor to meet a user's functional requirements,
such a specification will not ensure portability of software, written to the
interface, across product lines from multiple vendors. Work underway in the
IEEE 1003.8 POSIX networking services interface committee should create, in
the future, a series of service interface specifications that will enable
portability of software written to those specifications. In the interim,
Acquisition Authorities requiring service interfaces that enable software
portability must include a very detailed and explicit interface specification
within the solicitation. Such a specification is difficult and expensive to
produce, and will limit the number of vendors that bid on a solicitation.
Thus, this practice is not recommended. A more prudent course, at the present
time, is to specify the general functional and operational objectives of a
service interface, leaving implementation decisions to the vendor.
4.1.3 Performance Requirements
The Acquisition Authority must specify performance requirements. Performance
of an open system is a function of: 1) the source end system, 2) the
destination end system, and 3) the communications links, subnetworks, and
intermediate systems between the two end systems. The Acquisition Authority's
best strategy, given these difficult-to-control factors, is to specify
performance requirements for the principal operating environment of the end
system. For example, if the communicating end systems will generally be on
the same token bus network, detailed performance profiles should be developed
for that environment. If these systems must occasionally communicate over a
packet data network between local area networks (LANs), then a test for
correct interoperation in this occasional environment, without strict
performance requirements, should also be included.
4.2 END SYSTEM SPECIFICATION
4.2.1 Physical Layer
15
GOSIP does not mandate any specific physical interface standard. However, the
Acquisition Authority must specify physical layer requirements in a
solicitation. The following interfaces are recommended. The three standards
most commonly used in conjunction with X.25 are Electronic Industries
Association (EIA) RS-232-C [EIA 1] for line speeds up to 19.2 kilobits/second,
V.35 [CCITT 16] for line speeds above 19.2 kilobits/second, and EIA RS-530 for
transfer rates above 20 kilobits/second. For IEEE 802 LANs, the physical
interface characteristics are identified in ISO 8802/3 for CSMA/CD, ISO 8802/4
for token bus, and ISO 8802/5 for token ring, [ISO 29-31]. Additional
specifications for these interfaces, including subsets, options, and parameter
settings are included in the Workshop Agreements [NIST 1]. For ISDN, GOSIP
provides for the basic rate interface (BRI) at the S, T, and U reference
points [ANSI 1-2] and the primary rate interface (PRI) at the U reference
point [ANSI 3]. The BRI provides a 16 kilobits/second signalling (D) channel
and up to two 64 kilobits/second switched (B) channels. The PRI provides a 64
kilobits/second signalling (D) channel and up to twenty-three 64
kilobits/second switched (B) channels.
Other, non-proprietary, physical interface standards may be selected depending
upon unique requirements of the Acquisition Authority; however, the
Acquisition Authority must take special care to ensure appropriate operation
of such interfaces within a procured system. The Acquisition Authority is
advised to make a selection from the set of recommended physical interfaces.
4.2.2 Data Link Layer
The data link layer protocols shall be selected by the Acquisition Authority
from among the following: 1) High Level Data Link Control (HDLC) Link Access
Procedure B (LAP B), in conjunction with X.25 [NIST 1,3; ISO 26] and Pt-Pt
subnetworks; 2) ISO 8802/2 (LLC 1) in conjunction with ISO 8802/3, ISO 8802/4,
or ISO 8802/5 [NIST 1; ISO 28], and 3) Q.921 (LAPD) [CCITT 25] for operation
on the ISDN D channel and ISO 7776 (LAP B) for operation on ISDN B channels.
These protocols shall conform to the Workshop Agreements.
4.2.3 Network Layer Service
For GOSIP end systems, the connectionless network service (CLNS) is mandated
for Government-wide interoperability and provides the required means of
interconnecting logically distinct local and long-haul subnetworks. When a
GOSIP end system is connected to a local area or Pt-Pt subnetwork, the CLNP
end system to intermediate system (CLNP ES-IS) dynamic routing protocol is
required. The connection-oriented network service is an option available to
GOSIP end systems directly connected to an X.25 subnetwork or ISDN. The
technology for providing X.25 and ISDN subnetworks may be used to support the
mandated CLNS and the optional CONS; in either case certain subnetwork access
protocols are required. These topics are elaborated in the following
paragraphs.
4.2.3.1 Connectionless Mode Network Service
16
The Connectionless Mode Network Service (CLNS) shall be provided by the ISO
Connectionless Network Protocol (CLNP) [NIST 1; ISO 4,7]. The CLNP must be
implemented and used for internetworking of concatenated subnetworks. For
operation on a single logical subnetwork, the CLNP also must be implemented.
When an end system is connected to a local area or Pt-Pt subnetwork the CLNP
ES-IS protocol must be implemented and used.
4.2.3.1.1 Provision of the Connectionless Network Service
This service shall be provided according to the Workshop Agreements, section
3.5, with the following modifications and additions:
Add to the first bullet of section 3.5.1(2), the following:
o An End System must provide a configuration mechanism to control
the value to be assigned to the Lifetime parameter for PDUs which
it originates.
Replace the first bullet of section 3.5.1(3) Optional Functions with the
following:
o The use of the security parameter shall be in accordance with
section 6 of this specification, if required by the Acquisition
Authority.
Add as section 3.5.2(4):
o The CLNS shall be provided with interfaces to the 1984 CCITT
Recommendation X.25, HDLC LAP B (ISO 7776), ISO 8802.2 and Draft
International Standard (DIS) 9574 (ISDN), as selected by the Acquisition
Authority. When interface to DIS 9574 is provided, the provisions of
ISO 8878 are not used.
Section 3.5.3 of the Workshop Agreements is to be implemented by those systems
operating over X.25. Section 3.5.4 of the Workshop Agreements is to be
implemented by those systems operating over ISDN.
4.2.3.1.2 Provision of The End System To Intermediate System Routing Service
For end systems connected to local area and Pt-Pt subnetworks, the end system
to intermediate system (CLNP ES-IS) routing service shall be provided by the
ES-IS protocol ISO 9542 [ISO 44] implemented as specified in the Workshop
Agreements section 3.8.1. For end systems connected to wide-area networks,
provision of an end system to intermediate system routing service is network
specific.
4.2.3.2 Connection-Oriented Network Service
The CONS is an additional, optional service that may be specified for end
systems that are directly connected to X.25 wide area networks and ISDNs. Use
of this service can, under certain circumstances, avoid the overhead
17
associated with CLNP and may permit interoperation with end systems that do
not comply with GOSIP (i.e., do not implement CLNP). When an Acquisition
Authority specifies the CONS option, CONS shall be provided by the X.25 Packet
Level Protocol (PLP) [ISO 2]. The mapping of the elements of the CONS to the
elements of the X.25 PLP is according to ISO 8878 [ISO 8]. This service shall
be provided as specified in section 3.6.1 of the Workshop Agreements with the
following modifications:
o Section 3.6.1.3 does not apply.
When providing CONS in an ISDN, the considerations for control of B and D
channels shall be provided by DIS 9574 [ISO 45] and implemented according to
section 3.6.1.4 of the Workshop Agreements.
(Note that use of X.25 in GOSIP is consistent with FIPS 100-1 which requires
CCITT X.25-1984, ISO 7776, and ISO 8202 until January 1, 1993. After that
time, additional items covered in CCITT X.25-1988 are mandated by FIPS 100-
1.)
4.2.3.3 Network Layer Protocol Identification
OSI systems require the ability to identify which OSI protocols and services
are used in a particular instance of communication. These rules for
identification are specified in ISO DTR 9577 [ISO 43]. GOSIP systems shall
implement the protocol identification rules as specified in section 3.9.2.2 of
the Workshop Agreements.
4.2.3.4 Special Provisions For Integrated Services Digital Networks
Integrated services digital networks (ISDN) enables X.25 PLP data to be sent
across the D channel, sharing the channel with signaling data, and across a B
channel. The Acquisition Authority must specify whether one or both of these
capabilities are required. When operation of X.25 over a B channel is
selected, the B channel can be provided as a switched service or a permanent
service. The Acquisition Authority must specify whether one or both of these
capabilities are required.
(Note that at the present time switched access to the B channel is available
from most ISDN vendors, but not in a standard fashion; thus, multi-vendor
interoperability between terminal equipment and switching equipment is not
widely available today. Work underway in the North American ISDN Implementors'
Workshop (IIW) is expected to improve this situation in the future. As
appropriate IIW Agreements are developed, and related ISDN FIPS are issued by
NIST, GOSIP will be updated accordingly.)
ISDN provides the possibility of a BRI (16 Kbps D-channel + 2 64 Kbps B-
channels) or a PRI (64 Kbps D-channel + 23 64 Kbps B-channels). The
Acquisition Authority must specify whether BRI or PRI is required for each
system. The BRI service interface might be available at the S, T, or U
reference point. The Acquisition Authority must specify the physical
interface required for each BRI system.
18
ISDN B-channel services can be used by a GOSIP end system in any of six ways:
1) circuit-switched access to a packet handler integral to an ISDN
switch;
2) circuit-switched access to a packet handler separate from an ISDN
switch;
3) circuit-switched access directly to another GOSIP end system, or GOSIP
intermediate system;
4) dedicated circuit access to a packet handler integral to an ISDN
switch;
5) dedicated circuit access to a packet handler separate from an ISDN
switch, and
6) dedicated circuit access to another GOSIP end system or GOSIP
intermediate system.
The Acquisition Authority must specify the B-channel access capabilities
required for any GOSIP end system intended for use with ISDN B-channel
services.
For ISDN physical layer access at the S, T, and U reference points, sections
2.7.2.1 and 2.7.2.2 of the Workshop Agreements apply. For data link layer
access on the D channel, section 2.7.2.4 of the Workshop
Agreements applies. For signaling on an ISDN interface, section 2.7.2.5 of
the Workshop Agreements applies. For data link layer access on a B channel,
section 2.7.2.6 of the Workshop Agreements applies. The PLP for use on ISDN B
and D channels shall be implemented as specified in section 2.7.2.7 of the
Workshop Agreements.
4.2.4 Transport Layer
For GOSIP end systems, the connection-oriented transport service (COTS), as
provided by Transport class 4, is mandated for Government-wide
interoperability and is the required means of providing a reliable end-to-end
data communications path between end systems. The connectionless transport
service (CLTS) is an option available for GOSIP end systems.
4.2.4.1 Connection-Oriented Transport Service
The vendor shall provide Transport class 4 [NIST 1; ISO 12,13] according to
section 4.5.1 of the Workshop Agreements, with the modifications and additions
stated below. Transport class 0 [NIST 1; CCITT 10,11] is to be used as
appropriate in accordance with the CCITT X.400 recommendations (see section
4.2.7.3 of this profile).
Replace the sixth bullet of the Workshop Agreements section 4.5.1.2.1 with the
following:
o It is recommended that implementations not send user data in the
CR or CC TPDU. Any user data received in a CR or CC TPDU will be
made available to the Transport Service user.
19
Replace the seventh bullet of the Workshop Agreements section 4.5.1.2.1 with
the following:
o It is recommended that implementations not send user data in the
DR TPDU. Any user data received in a DR TPDU will be made
available to the Transport Service user.
Add, as the thirteenth bullet of the Workshop Agreements section 4.5.1.2.1,
the following:
o Transport expedited shall be provided as an optional service for
the Transport Service user.
In specifying operator and higher layer protocol access controls in transport,
the Acquisition Authority should be guided by the implementation guide and
military supplement [NIST 5,6].
4.2.4.2 Connectionless Mode Transport Service
The Acquisition Authority may specifiy the optional connectionless mode
transport service (CLTS) for GOSIP end systems [ISO 46]. This option may be
specified only as an addition to the connection-oriented transport service.
Although no GOSIP mandated protocols require the CLTS, a number of non-GOSIP
protocols widely available in industry can use CLTS as an efficient means of
communicating across local area networks. The Acquisition Authority must
determine the need for CLTS to support non-GOSIP protocols.
The CLTS option shall be implemented using IS 8602 [ISO 47] according to
section 4.6 of the Workshop Agreements [NIST 1].
4.2.5 Session Layer
The vendor shall provide the Session protocol as specified in section 5.9 and
section 5.12 of the Workshop Agreements. Application layer protocols
determine the session layer functional units needed for their support.
Current and future needs should be considered when selecting Session layer
functional units. [NIST 1; ISO 14,15; CCITT 12,13].
4.2.6 Presentation Layer
The vendor shall provide the Presentation protocol as specified in section 5.8
and section 5.12 of the Workshop Agreements. See References [NIST 1; ISO 20,
21, 24, 25].
4.2.7 Application Layer
4.2.7.1 Association Control Service Elements (ACSE)
The ACSE, as specified in section 5.5 and section 5.12 of the Workshop
Agreements, is required to support all applications except Message Handling
Systems. See section 4.2.7.3 of this profile. See References [NIST 1; ISO
20
22-25]. Section 5.12.1.1 of the Workshop Agreements defines a fixed value for
the Application Entity (AE) Title in order to satisfy the FTAM requirement for
exchanging fields of this type; however, for compatibility with non-GOSIP
systems, and to ease compatibility with future versions of GOSIP, GOSIP
systems must allow locally configurable AE Titles to be generated and
received.
4.2.7.2 File Transfer, Access, and Management Protocol (FTAM)
The following categories of FTAM systems are defined for procurement purposes:
(1) limited-purpose systems, and (2) full-purpose systems. These categories
are defined by their support requirements given below. All FTAM systems in
these categories are bound by the language and conditions for Phase 2 FTAM
implementations contained in section 9 of the Workshop Agreements. [NIST 1]
(Hereafter section 9.)
A limited-purpose FTAM system provides the functions of simple file transfer
and management. Such a system must support at least Implementation Profiles
T1 (Simple File Transfer) and M1 (Management) as defined in section 9.
Support requirements for Implementation Profiles are given in Table 9.7 of
section 9. A full-purpose FTAM system provides the functions of positional
file transfer (including simple file transfer), simple file access, and
management. Such a system must support at least Implementation Profiles T2
(Positional File Transfer), A1 (Simple File Access), and M1 (Management), as
these are defined in section 9. A limited-purpose FTAM system is able to
interoperate with a full-purpose FTAM system at the intersection of their
capabilities.
FTAM implementations (whether full-purpose or limited-purpose) can operate as
an initiator of remote file activity, as a responder to requests for remote
file activity, or as both initiator and responder. Further, FTAM
implementations can operate as senders (of data to receivers), receivers (of
data from senders), or as both. Thus, any of four possible roles may be
assumed as follows: initiator-sendor, initiator-receiver, responder-sender,
and responder-receiver. The Acquisition Authority must determine the
requirements for each FTAM device and must specify such requirements in terms
of initiator, responder, sender, and receiver, as well as in terms of limited-
purpose or full-purpose.
4.2.7.3 Message Handling Systems
The vendor shall provide all Message Transfer Services and Interpersonal
Messaging Services specified in section 7 of the Workshop Agreements. [NIST 1]
Communication between two Message Transfer Agents, one or both of which reside
entirely and exclusively within a public message domain administered by a
public data network, takes place as specified by CCITT Recommendation X.410
(1984). CCITT mandates that transport class 0 and the Connection Oriented
Network Service (CONS) [ISO 2, 3] be used by end systems when messaging over
public messaging domains on public data networks. All end systems on private
management domains must use transport class 4. Private management domain end
systems that are also connected to public messaging domains conforming to
CCITT Recommendation X.410 must also implement and use transport class 0 when
21
acting as a messaging relay between the two domains. Specifically, the
Message Transfer Agent in the system connected to both the private and public
messaging domain performs the relay; there is no transport relay involved.
4.2.7.4 Virtual Terminal (VT) Basic Class
The following categories of VT systems are defined for procurement purposes:
1) simple systems, and 2) forms capable systems. All VT systems in these
categories are bound by the language and conditions contained in section 14 of
the Workshop Agreements.
A simple system provides the functions of a TTY compatible device. It
supports a dialogue which is a simple line or character at a time. Such a
system uses the control character (single) functions from the ASCII character
set, such as "carriage return," "form feed," "horizontal tab," and "back
space." A simple system supports the TELNET profile specified in section
14.8.1 of the Workshop Agreements. The TELNET profile requires the
Asynchronous mode (A-mode) of operation (i.e., no token handling protocols are
needed) and specifies simple delivery control.
A forms-capable system is intended to support forms-based applications with
local entry and validation of data by the terminal system. A forms-capable
system supports functions such as "cursor movement," "erase screen," and
"field protection." A forms-capable system supports the forms profile
specified in section 14.8.3 of the Workshop Agreements. The forms profile
requires the Synchronous mode (S-mode) of operation and specifies simple
delivery control.
The Basic Class VT International Standard [ISO 32] specifies three negotiation
options which are independent of the VT profiles. These are No Negotiation,
Switch Profile, and Multiple Interaction Negotiation. Multiple Interaction
Negotiation is not addressed by the Workshop Agreements, but any system
claiming support of this negotiation option must also support the Switch
Profile and No Negotiation options. Any system supporting Switch Profile
Negotiation must also support the No Negotiation option. Seven bit USASCII,
as well as the International Reference Version (IRV) of ISO-646 graphic
repertoires, must be supported by both simple and forms capable systems.
4.2.8 Exchange Formats
Exchange formats are not OSI standards. They are included in GOSIP because
the information that they describe can be transported by the OSI FTAM and MHS
protocols either as the content of a file or as the body part of a message.
The GOSIP contains only that information about exchange formats that are
required to provide this capability. For detailed specifications on the
exchange formats, consult the appropriate standards documents or the Workshop
Agreements.
Version 2 of GOSIP includes information on how to identify and transport the
ODA exchange format. Future versions of GOSIP will include information on how
22
to identify and transport additional formats such as Computer Graphics
Metafile (CGM) and the Standard General Markup Language (SGML). For further
details, see Appendix 4.
ODA information can also be transported by other mechanisms which are outside
the scope of the GOSIP.
4.2.8.1 Office Document Architecture (ODA)
The ODA Standard [ISO 36-42, CCITT 17-24] specifies rules for describing the
logical and layout structures of documents as well as rules for specifying
character, raster, and geometric content of documents, thus, providing for the
interchange of complex documents. The interchanged documents may be in
formatted form (i.e., for presentation such as printing, displaying), in
processable form (i.e., for further processing such as editing) or in
formatted processable form (i.e., for both presentation and further
processing).
To transfer an ODA file, the services provided by either the MHS or FTAM
application can be used.
If the MHS application is used, OdaBodyParts are encoded for transmission over
a CCITT X.400-1984 service as a single body part with tag 12 in the P2
protocol.
Oda [12] IMPLICIT OCTETSTRING
The content of the OCTETSTRING is a SEQUENCE of OdaBodyPart Parameters and
OdaData components with a value of type OdaBodyPart.
OdaBodyPart :: = SEQUENCE {
OdaBodyPart Parameters,
OdaData }
The OdaBodyPart Parameters component is a SET containing the document-
application-profile and the document-architecture-class identifiers
OdaBodyPart Parameters :: = SET {
document-application profile [0] IMPLICIT OBJECT IDENTIFIER
document-architecture-class [1] IMPLICIT INTEGER {
formatted (0),
processable (1),
formatted-processable (2) }}
The OdaData component is a SEQUENCE of Intercharge-Data Element as defined by
IS 8613-5 [ISO 39]
OdaData :: = SEQUENCE of Interchange-Data-Element
In the P1 protocol, both the undefined bit (bit 0) and the ODA bit (bit 10) of
the Encoded Information Type must be set when an ODA document is present in
P2.
23
When using FTAM to transfer an ODA file, the FTAM-3 (ISO FTAM unstructured
binary) document type should be specified; however, since files that are not
ODA files can have the same document type, it is left up to the user of
application programs that remotely access files using FTAM to know that a
given file contains ODA information.
4.3 INTERMEDIATE SYSTEM SPECIFICATION
Intermediate systems shall operate in connectionless mode. That is, the
connectionless network protocol is used regardless of whether the underlying
technology operates in connectionless (e.g., CSMA/CD, token ring) or
connection-oriented (e.g., X.25, LAP B) mode; however, the connectionless mode
need not be used to interconnect X.25 subnetworks to form a single logical
subnetwork. Also note that local area network bridges may be employed to form
a single logical subnetwork.
Intermediate systems may use any combination of the lower layer technologies
as specified in the above sections of this profile: 4.2.1 Physical Layer,
4.2.2 Data Link Layer, and 4.2.3 Network Layer. That is, agencies may
interconnect local and wide area networks. Implementation profiles for these
protocols are contained in the Workshop Agreements and are referenced in the
above sections of this profile. Implementation specifications for
connectionless-mode intermediate systems are given in section 3.5 of the
Workshop Agreements.
Addressing structure and Address Registration Authorities are specified in
section 5 of this profile.
A system that serves as both end system and intermediate system must satisfy
the mandatory requirements of sections 4.2 and 4.3 of this profile.
24
5. ADDRESSING REQUIREMENTS
5.1 NETWORK LAYER ADDRESSING AND ROUTING
This section specifies the Network Layer addressing scheme and its
administrative and routing implications. It also identifies authorities
responsible for the administration of the scheme and how subauthorities will
be assigned and which responsibilities shall be delegated to them.
5.1.1 NSAP Address Administration, Routing Structures and NSAP Address
Structure
Network Service Access Point (NSAP) addresses specify the points where the
communication capability of the Network Layer (i.e., the Network Service) is
made available to its users. In effect they address the direct users of the
Network Service, normally transport entities. The semantics of NSAP addresses
are encoded into Network Protocol Address Information (NPAI) and conveyed in
the appropriate protocol data units (PDUs) between protocol entities providing
the Network Service.
The basic principles of Network Layer addressing, as defined in Addendum 2 to
the Network service definition [ISO 5], include:
o NSAP address administration is based on the concept of
hierarchical Addressing Domains. An Addressing Domain is a set of
addresses interrelated by virtue of being administered by a common
authority. The term authority refers to the entity that specifies
the structure and ensures the uniqueness of identifiers in the
associated domain. In practice the structure of NSAP addresses
reflects this administrative hierarchy in that, at any level of
the hierarchy, an initial part of the address unambiguously
identifies the Addressing (sub) Domain.
o The first three levels of the NSAP
addressing domain are standardized and
result in the NSAP address structure in
Figure 5.1.1. The Initial Domain Part
(IDP) of the address consists of two
parts, the Authority and Format Identifier
(AFI) and the Initial Domain Identifier
(IDI). The AFI specifies the format of
the IDI, the authority that is responsible
for allocating IDI values, and the syntax
used to represent the Domain Specific Part
(DSP). The IDI is interpreted according
to the value of the AFI and its value
identifies the authority responsible for
the structure and assignment of DSP
values. The DSP is allocated and assigned
by the authority specified by the IDP
part.
25
ZDDDDDDDDDDDDDDDD?
3 IDP 3
CDDDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDD?
ISO/CCITT NSAP ADDRESS 3 AFI 3 IDI 3 DSP 3
@DDDDDDDDADDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDY
Figure 5.1.1 NSAP Address Structure
The National Institute of Standards and Technology (NIST) has been designated
as the authority to administer the addressing domain identified by IDI value
0005 under AFI 47. The AFI value of decimal 47 specifies that the IDI part is
interpreted as a four decimal digit International Code Designator (ICD) and
that the DSP has a binary abstract syntax. ICDs are allocated and assigned by
ISO [ISO 27] and identify international organizations that are the authorities
for address administration for an addressing subdomain.
The addressing domain identified by ICD 0005 shall be available for use by all
of the Federal Government. The NIST shall specify the structure and semantics
of the DSP associated with ICD 0005 and delegate the task of administering the
assignment of DSP values to the General Services Administration (GSA). This
is summarized in Figure 5.1.2.
26
ZDDDDDDDDDDDDDD?
3 IDP 3
CDDDDDDDBDDDDDDEDDDDDDDDDDDDDDDDDDDD?
ISO/CCITT NSAP Address 3 AFI 3 IDI 3 DSP 3
CDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDDDDDD4
Fed. Govt. NSAP Address 3 47 3 0005 3structure specified 3
3 3 3by GOSIP 3
@DDDDDDDADDDDDDADDDDDDDDDDDDDDDDDDDDY
Figure 5.1.2 The NIST ICD Addressing Domain
NSAP addresses, encoded as NPAI in appropriate NPDUs, serve as the primary
input to the routing and relaying functions of protocol entities providing the
Network Service. As such, the semantics of NSAP addresses must convey
information required for routing as well as address administration.
The basic principles of Network Layer routing, as defined in the OSI Routing
Framework [ISO 48], include:
o The global OSI environment will consist of a number of Administrative
Domains. An Administrative Domain consists of a collection of End
Systems (ESs) and Intermediate Systems (ISs), and subnetworks
operated by a single entity or Administrative Authority. The
Administrative Authority is responsible for the organization of ESs
and ISs into Routing Domains; the further structuring and assignment
of NSAP addresses; the policies that govern the information that is
collected and disseminated both internally and externally to the
Administrative Domain; and, the establishment of subdomains and the
corresponding delegation of responsiblities.
o A Routing Domain is a set of ESs and ISs which operate
according to the same routing procedures and which is wholly
contained within a single Administrative Domain. An
Administrative Authority may delegate to the entity
responsible for a Routing Domain the responsibilities to
further structure and assign NSAP addresses. The
hierarchical decomposition of Routing Domains into
subdomains may greatly reduce the resources required in the
maintenance, computation and storage of routing information.
This GOSIP makes provisions for the establishment of Administrative Domains,
Routing Domains and one level of routing subdomains (called Areas). This
decomposition of the routing environment allows, where appropriate,
administrative entities to request the delegation of responsibility for the
organization and administration of their systems and subnetworks. The
provision of two levels of routing structures within an Administrative Domain
will allow Administrative Authorities to engineer routing configurations that
best serve their individual needs.
Figure 5.1.3 depicts the GOSIP NSAP address structure. This structure is
27
mandatory for addresses allocated from the ICD 0005 addressing domain.
ZDDDDDDDDDDDDDD?
3 IDP 3
CDDDDDDBDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 AFI 3 IDI 3 DSP 3
CDDDDDDEDDDDDDDEDDDDDDDDDDDBDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDD4
3 47 3 0005 3 DFI 3 Admin Author. 3 Reserved 3 Routing Domain 3 Area 3 System 3 NSel 3
CDDDDDDEDDDDDDDEDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDD4
Octets 3 1 3 2 3 1 3 3 3 2 3 2 3 2 3 6 3 1 3
@DDDDDDADDDDDDDADDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDADDDDDDDDDDDDDDDADDDDDDDDY
Figure 5.1.3 GOSIP NSAP Address Structure
28
The DSP Format Identifier (DFI) specifies the structure, semantics and
administration requirements associated with the remainder of the DSP. This
field provides for graceful support of future DSP structures should the need
arise. Currently, only one DSP format (DFI=10000000) is defined under ICD
0005. The remainder of this section describes this DSP format.
The Administrative Authority field identifies the entity that is responsible
for the organization of ISs and ESs into Routing Domains and Areas; the
allocation and assignment of the remaining portion of the DSP; and the
policies that govern the dissemination of information within and external to
the Administrative Domain. Note that it is unlikely that a large number of
Federal Government organizations will establish their own Administrative
Domains. Instead, it is more likely that Administrative Domains will be
established for collective organizations that autonomously operate large
inter-networks and that individual organizations would correspondingly be
delegated authority for Routing Domains or Areas.
The Reserved field is positioned to be available for encoding higher level
routing structures above those of the routing domain or to be used to expand
either the Administrative Authority or the Routing Domain fields in future DSP
formats should the need arise.
The Routing Domain field identifies a unique Routing Domain within an
Administrative Domain.
The Area field identifies a unique subdomain of the Routing Domain.
The System field identifies a unique system (ES or IS) within an Area. The
format, value, structure and meaning of this field is left to the discretion
of its administrator.
The NSAP Selector field identifies a direct user of the Network Layer service,
usually a Transport entity. (The NSAP Selector may also identify other direct
users of the Network Service if required by the Acquisition Authority.)
GOSIP allows a system administrator to configure NSAP Selector-to-Transport
entity mappings because, for example, several transport entities may co-exist
in some systems.
5.1.2 NSAP Address Registration Authorities
This section names the GSA as the GOSIP Address Registration Authority, and
specifies how subauthorities shall be assigned, and which responsibilities
transfer to them.
Under its delegated authority as Address Registration Authority for ICD 0005,
GSA shall, upon request, assign, maintain, and publicize unique Administrative
Authority identifiers for Federal Government entities that require distinct
Administrative Domains. Contact GSA at:
Telecommunications Customer Requirements Office
U. S. General Services Administration
IRMS
29
Office of Telecommunications Services
18th & F Sts. N.W.
Washington, D. C. 20405
for the procedures for requesting the assignment of an Administrative
Authority identifier. They are also included in Version 2 of the GOSIP User's
Guide.
5.1.2.1 Responsibilities Delegated by NIST
The management responsibilities delegated by the NIST, via the GSA, to Federal
Government entities issued an Administrative Authority identifier under ICD
0005 are given below.
o The entity must designate and register with the GSA a specific
point of contact for its Administrative Authority.
o The entity must ensure that procedures exist to establish
appropriate routing structures and to delegate, if required,
responsibliities to the administrators of individual Routing
Domains or Areas.
o The entity must ensure that addresses are assigned uniquely and
are kept current and accurate.
o The entity must ensure that policies are defined and procedures
exist for making addresses and routing information known to other
administrative domains.
o The entity may, on a voluntary basis, supply such
information to the GSA for government-wide compilation
and dissemination. The GOSIP Users' Guide [NIST 7]
lists the factors that Administrative Authorities
should consider before requesting this service and the
procedures to be followed if the service is required.
5.1.3 GOSIP Routing Procedures
This GOSIP specifies dynamic routing procedures for the exchange of
configuration information between ESs and ISs connected via local area and
point to point (pt-pt) subnetworks and hierarchical, static routing procedures
for the establishment of routing information among ISs. These routing
procedures shall be provided according to section 3.8 of the Workshop
Agreements, with the following additions after the paragraph of section 3.8.2:
o The Routing Information Base (RIB) shall be capable of associating
arbitrary sets of NSAPs, described as NSAP address prefixes, with
next hop forwarding information for use by the ISO 8473 Route PDU
Function. In addition, the RIB must be capable of supporting a
default entry that is used in forwarding PDUs containing
destination NSAP addresses that do not match any other RIB
entries.
30
Nonstandard dynamic routing procedures, in addition to the static capabilities
specified above, may be used to establish RIBs within ISs in the interim
period while OSI IS-IS dynamic routing protocols are still under development.
It should be noted that the GOSIP supported routing structures and DSP
addressing structure are in alignment with the OSI IS-IS intra-domain routing
protocol [ISO 49] currently under development and that later versions of this
profile will mandate the use of standardized OSI IS-IS routing protocols.
The routing procedures required for GOSIP systems to communicate with non-
GOSIP OSI-compliant systems are discussed in Version 2 of the GOSIP User's
Guide.
5.2 UPPER LAYERS ADDRESSING
The following sections provide guidance on certain upper layer addressing
issues.
5.2.1 Address Structure
The address structure for the Session Service Access Point (SSAP) and
Transport Service Access Point (TSAP) Selector is two octets for each field,
encoded in binary as shown on Fig. 5.2.1. Other lengths conforming to the
limits specified in the Workshop Agreements, may be assigned by an end system
administrator.
31
PSAP SSAP TSAP
ZDDDDDDDDDDDD? ZDDDDDDDDDDDD? ZDDDDDDDDDDDD?
3 binary 3 3 binary 3 3 binary 3
@DDDDDDDDDDDDY @DDDDDDDDDDDDY @DDDDDDDDDDDDY
2 octets 2 octets 2 octets
Figure 5.2.1 Upper Layers Address Structure
5.2.2 Address Assignments
Service access point (SAP) selectors specify the addresses of standard service
interfaces. Values are assigned by an end system administrator and must be
configurable in GOSIP end systems. T-selectors and S-selectors are each
encoded as a string of octets. The octet string may be specified as an
unsigned integer; if so, the high order octet precedes low order octets. P-
selectors are encoded in Abstract Syntax Notation (ASN).1 type OCTETSTRING as
per the Presentation protocol specification [ISO 21].
The Application Context Name can be used to distinguish the Application
entities that use the common application services of ACSE. The Application
Context Names for FTAM and VT, as specified in sections 5.12.1.1 and section
5.12.1.4 of the Workshop Agreements, are "ISO FTAM" and "ISO VT." Note that
applications which require additional Application Context information may
define them, even if they make use of FTAM and/or VT.
5.2.3 Address Registration
As an interim measure, until Directory Service implementations are available,
federal agencies that wish to have their PSAP address (upper layer SAP
selector values plus full NSAP address) accessible to other agencies may
register these addresses with GSA. GSA shall catalog, maintain, and
disseminate these addresses.
5.3 IDENTIFYING APPLICATIONS
5.3.1 FTAM and File Transfer User Interface Identification
The FTAM service definition [ISO 18] includes an optional parameter called the
initiator identity. GOSIP recommends the use of this parameter in FTAM
implementations to identify users of the service. Generally, an identifying
name or group of names is provided in this field. The name identifies the
particular user in such a way that two different users may readily be
distinguished. In the standard there are no restrictions on what may be
included. The initiator identity is encoded as an ASN.1 [ISO 25] variable
length graphic string with characters from the ISO646 set [ISO 9]. These names
are normally inserted as needed by end systems, and this profile makes no
provision for registration. The content is system-dependent.
5.3.2 MHS and Message User Interface Identification
The MHS Recommendations [CCITT 2-9] identify a user to a Message Transfer
Agent by means of a parameter called the Originator/Recipient Name (O/R Name).
32
The O/R Name is encoded as a set of attributes describing the originator and
receiver of the message. The attributes which must be supported by all
implementations are the country name, the administration name, private domain
name, organization name, organizational units, and personal name. The
administration name attribute shall contain one blank when the originator
and/or recipient are attached only to a private domain. The private domain
name attribute must also be supported by all implementations, and be included
when the originator and/or the recipients are located within different private
domains. This information is summarized in Table 5.3.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Attribute Maximum ASCII Character Length 3
3 3
3 country name 3 3
3 administration name 16 3
3 private domain name 16 3
3 organization name 64 3
3 sequence of org. units 32 each 3
3 personal name 64 3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Table 5.3 Required O/R Name Attributes
Private messaging systems within the government shall be capable of routing on
the administration name, private domain name, organization name and
organizational unit attributes taken in their hierarchical order. They shall
also be capable of routing on or delivering based on the personal name
attribute; that is, they shall act as Class 2 or Class 3 MTAs as defined in
section 7.7.3.3 of the Workshop Agreements. The General Services
Administration (GSA) shall be the Address Registration Authority for
organization names. GSA shall delegate Address Registration Authority to the
organization indicated by the organization name to assign organization unit
and personal names. In assigning the organizational unit personal name space,
the Address Registration Authorities shall follow the same rules stated
earlier for NSAP addresses, except that organizational unit and personal names
are not registered with GSA. Typically, a unique personal name is a surname
or surname followed by given name, but it could also be an identifier of a
particular office within the organization unit.
CCITT assigns country name and administration name to public message service
providers. Administrations assign private domain names to private messaging
systems that wish to interoperate across the administration. The
administration may also provide a registration service for government assigned
organization names that wish to interoperate across or between administrative
domains. A method for assigning private domain names in the absence of an
administrative name is given in section 8.4.2 of Version 2.0 of the GOSIP
User's Guide.
33
6. SECURITY OPTIONS
Security is of fundamental importance to the acceptance and use of open
systems in the U.S. Government. Part 2 of the Open Systems Interconnection
reference model (Security Architecture) is now an International Standard (IS
7498/2). The standard describes a general architecture for security in OSI,
defines a set of security services that may be supported within the OSI model,
and outlines a number of mechanisms than can be used in providing the
services. However, no protocols, formats or minimum requirements are
contained in the standard.
The text below describes one security option that may be optionally specified
when security services are incorporated in the OSI network layer. This
chapter does not describe at this time a complete set of security options that
a user might desire nor a description of the security services and protocols
that are associated with the specified parameter. It is a parameter that has
been identified as being needed if certain security services (e.g.,
confidentiality, access control) are incorporated in the network layer. The
parameter should be used where required, but this chapter should be considered
as a placeholder for future security specifications. Appendix 1 provides
further information on what specifications are considered needed for OSI
security.
As defined by ISO, security features are considered both implementation and
usage options. An organization desiring security in a product that is being
purchased in accordance with this profile must specify the security services
required, the placement of the services within the OSI architecture, the
mechanisms to provide the services and the management features required. An
acquisition authority desiring Connectionless Network Protocol (CLNP) security
should specify the following described security option(s). When specifying
the CLNP security option, the acquisition authority must ensure that all
necessary Security Format Codes are provided.
6.1 REASON FOR DISCARD PARAMETERS
The implementation of the security option requires assigning new parameter
values to the Reason for Discard parameter in the CLNP Error Report PDU. The
first octet of the parameter value contains an error type code as described in
IS 8473. Values beyond those assigned in the standard are shown in Table 6.1.
The second octet of the Reason for Discard parameter value either locates the
error in the discarded PDU or contains the value zero as described in the
standard.
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDD?
3 Parameter Values 3 3 3
CDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD4 3 3
3 Octet 1 3 Octet 2 3 Class of 3 Meaning 3
3Bits 8765 4321 3 Bits 8765 4321 3 Error 3 3
3 3 3 3 3
CDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDD3
34
3 1101 0000 3 Discarded PDU 3 Security 3 Security Option 3
3 3 Offset or Zero 3 3 Out-of-Range 3
3 3 3 3 3
3 1101 1010 3 0000 0000 3 Security 3 Basic Portion 3
3 3 3 3 Missing 3
3 3 3 3 3
3 1101 1101 3 0000 0000 3 Security 3 Extended Portion 3
3 3 3 3 Missing 3
3 3 3 3 3
3 1101 0010 3 0000 0000 3 Security 3 Communication 3
3 3 3 3 Administratively 3
3 3 3 3 Prohibited 3
3 3 3 3 3
@DDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDY
Table 6.1 Extended Values in the Reason For Discard
Parameter
6.2 SECURITY PARAMETER FORMAT
IS 8473 defines the format of the CLNP security parameter. This parameter
consists of the three fields shown in Table 6.2.
Bits 8765 4321
ZDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDD?
3 Octets 3 3
3 3 1100 0101 3 Parameter Code
3 N 3 3
CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
3 3 3
3 N + 1 3 Len = M 3 Parameter Length
3 3 3
CDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDD4
3 N + 2 3 3
3 3 3 Parameter Value
3 N + M + 1 3 3
@DDDDDDDDDDDDDDADDDDDDDDDDDDDDDDY
Table 6.2 Security Parameter Format
6.2.1 Parameter Code
IS 8473 assigns the value "1100 0101" to the Parameter Code field to identify
the parameter as the Security Option.
6.2.2 Parameter Length
This octet indicates the length, in octets, of the Parameter Value field.
6.2.3 Parameter Value
The Parameter Value field contains the security information. IS 8473 defines
only the first octet of the Parameter Value field. This section completes the
35
definition of this field. Table 6.3 illustrates the format of the Parameter
Value field within the Security Parameter.
Bits 8765 4321
ZDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDD?
3 Octets 3 3
3N 3 1100 0101 3 Parameter Code
CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4
3 3 3
3N+1 3 Len = B + E + 1 3 Parameter Length
3 3 3
CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
3 3 3 3
3N+2 3 XX00 0000 3 Security Format Code 3
3 3 3 3
CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4 3
3N+3 3 3 Parameter
3 3 3 Basic Portion (Optional) Value
3N+B+2 3 3 3
CDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDD4 3
3N+B+3 3 3 3
3 3 3 Extended Portion (Optional) 3
3N+B+E+2 3 3 3
@DDDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Table 6.3 Format - Parameter Value Field
36
6.2.3.1 Security Format Code
As described in IS 8473, the high order two bits of the first octet of the
Parameter Value field specify the Security Format Code. The standard reserves
the remaining six bits and specifies that they must be zero.
6.2.3.2 Basic Portion
The Basic Portion of the Security Option identifies the U.S. classification
level to which a PDU is to be protected and the authorities whose protection
rules apply to that PDU. This portion is optional and appears at most once in
a PDU. When the Basic Portion appears in the Security Option of a PDU, it
must be the first portion in the Parameter Value field of the Security
Parameter. Paragraph 6.3 defines the format of the Basic Portion.
6.2.3.3 Extended Portion
The Extended Portion permits additional security labelling information, beyond
that present in the Basic Portion, to be supplied in a CLNP PDU to meet the
needs of registered authorities. This portion is optional and appears at most
once in a PDU. The Extended Portion must follow the Basic Portion, if
present, in the Parameter Value field of the CLNP Security Parameter. In
addition, if this portion is required by an authority for a specific system,
it must be specified explicitly in any Request for Proposal for that system.
Paragraph 6.4 defines the format of the Extended Portion.
6.3 BASIC PORTION OF THE SECURITY OPTION
The Basic Portion is used by the components of an internetwork to:
A. Transmit from source to destination, in a network standard
representation, the common security labels required by computer security
models.
B. Validate the PDU as appropriate for transmission from the source and
delivery to the destination.
C. Ensure that the route taken by the PDU is protected to the level
required by all protection authorities indicated on the PDU.
Table 6.4 shows the format of the Basic Portion of the Security Option.
Bits 8765 4321
ZDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDD?
3 Octets 3 3
3 N 3 1000 0010 3 Basic Type Indicator
3 3 3
CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4
3 3 3
3 N+1 3 Len = I 3 Length of Basic Information
3 3 3
CDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDD4
3 3 3
37
3 N+2 3 3
3 3 3 Basic Information
3 N+I+1 3 3
@DDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDY
Table 6.4 Format - Basic Portion
6.3.1 Basic Type Indicator
The value of this field identifies this as the Basic Portion of the Security
Option.
6.3.2 Length of Basic Information
This length field, when present, indicates the length, in octets, of the Basic
Information field. The Basic Information field is variable in length and has
a minimum length of two octets.
6.3.3 Basic Information
The Basic Information field consists of two subfields as Table 6.5
illustrates.
Bits 8765 4321
ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
3Octets 3 3
3 B 3 1000 0010 3 Basic Type Indicator
3 3 3
CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
3 3 3
3 B + 1 3 Len = F + 1 3 Length of Basic Information
3 3 3 (Minimum = 2 Octets)
CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
3 3 3 3
3 B + 2 3 3 Classification Level 3
3 3 3 3
CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4 Basic
3 3 3 Information
3B + 3 3 3 3
3 3 3 Protection Authority Flags 3
3B + F + 2 3 3 3
@DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
Table 6.5 Format - Basic Information Field
6.3.3.1 Classification Level
The Classification Level field specifies the U.S. classification level to
which the PDU must be protected. The information in the PDU must be treated
at this level unless it is regraded in accordance under the procedures of all
the authorities identified by the Protection Authority Flags. The field is
one octet in length. Table 6.6 provides the encodings for this field.
38
ZDDDDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDD?
3 VALUE 3 LEVEL 3
3 Bits 8765 4321 3 3
CDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDD4
3 0000 0001 3 RESERVED 4 3
3 0011 1101 3 TOP SECRET 3
3 0101 1010 3 SECRET 3
3 1001 0110 3 CONFIDENTIAL 3
3 0110 0110 3 RESERVED 3 3
3 1100 1100 3 RESERVED 2 3
3 1010 1011 3 UNCLASSIFIED 3
3 1111 0001 3 RESERVED 1 3
@DDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDY
Table 6.6 Classification Levels
6.3.3.2 Protection Authority Flags
The Protection Authority Flags field indicates the National Access Program(s)
or Special Access Program(s) whose rules apply to the protection of the PDU.
Its field length and source flags are described below. To maintain the
architectural consistency and interoperability of DoD common user data
networks, users of these networks should submit requirements for additional
Protection Authority Flags to DCA DISDB, Washington, D. C. 20305-2000 for
review and approval.
A. Field Length: The Protection Authority Flags field is variable in
length. The low order bit (Bit 1) of an octet is encoded as "0" if
the octet is the final octet in the field. If there are additional
octets, then the low order bit is encoded as "1". Currently, there
are less than eight authorities. Therefore, only one octet is
required and the low order bit of this octet is encoded as "0".
B. Source Flags: Bits 2 through 8 in each octet are flags. Each
flag is associated with an authority as indicated in Table 6.7. The
bit corresponding to an authority is "1" if the PDU is to be protected
in accordance with the rules of that authority.
ZDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Bit 3 3 3
3 Number 3 Authority 3 Point of Contact 3
CDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 3 3 3
3 8 3GENSER 3 Designated Approving Authority 3
3 3 3 per DoD 5200.28 3
3 3 3 3
3 7 3SIOP-ESI 3 Department of Defense 3
3 3 3 Organization of the 3
3 3 3 Joint Chiefs of Staff 3
3 3 3 Attn: J6T 3
3 3 3 Washington, D.C. 3
3 3 3 3
39
3 6 3 SCI 3 Director of Central Intelligence 3
3 3 3 Attn: Chairman, Information Handling Committee 3
3 3 3 Intelligence Community Staff 3
3 3 3 Washington, D. C. 20505 3
3 3 3 3
3 5 3 NSA 3 National Security Agency 3
3 3 3 9800 Savage Road 3
3 3 3 Attn: TO3 3
3 3 3 Ft. Meade, MD 20755-6000 3
3 3 3 3
3 4 3 DOE 3 Department of Energy 3
3 3 3 Attn: DP343.2 3
3 3 3 Washington, D.C. 20545 3
3 3 3 3
3 3 , 2 3 Unassigned 3 3
3 3 3 3
3 1 3 Extension Bit 3 Presently always "O" 3
@DDDDDDDDDDDADDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
Table 6.7 Protection Authority Bit Assignments
6.4 EXTENDED PORTION OF THE SECURITY OPTION
Table 6.8 illustrates the format for the Extended Portion. To maintain the
architectural consistency of DoD common user data networks, and to maximize
interoperability, users of these networks should submit their plans for the
use of the Extended Portion of the Security Option to DCA DISDB, Washington,
D.C. 20305-2000 for review and approval. Once approved, DCA DISDB will assign
Additional Security Information Format Codes to the requesting activities.
40
Bits 8765 4321
ZDDDDDDDDDDDDDBDDDDDDDDDDDDDDDDD?
3 Octets 3 3
3 N 3 1000 0101 3 Extended Type Indicator
CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
3 3 3
3 N+1 3 Len = I 3 Length of Extended Information
3 3 3
CDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDD4
3 N+2 3 3
3 3 3 Extended Information
3 N+I+1 3 3
@DDDDDDDDDDDDDADDDDDDDDDDDDDDDDDY
Table 6.8 Format - Extended Portion
6.4.1 Extended Type Indicator
The value of this field identifies this as the Extended Portion of the
Security Option.
6.4.2 Length of Extended Information
This length field indicates the length, in octets, of the Extended Information
field. The Extended Information field is variable in length with a minimum
length of two octets.
6.4.3 Extended Information
The Extended Information field consists of three subfields as Table 6.9
illustrates. These three fields form a sequence. This sequence may appear
multiple times, forming a set, within the Extended Information field.
41
Bits 8765 4321
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3 Octets 3
3 E 1000 0101 3 Extended Type Indicator
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3 E+1 Len = (B - A) + 1 3 Length of Extended
Information
3 3 (Minimum = 2 Octets)
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDEDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDD?
3 3
3
A 3 E+2 3 Additional Security
Information Format Code 3
3 3
3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3
3 3
3
3 E+3 Len = I 3 Length of Additional Security
Information 3
3 3
3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3
3 3
3
3 E+4 3
3
3 3 Additional Security
Information 3
3 E+I+3 3 (Zero or more octets)
3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDY
3
. .
3
. (Additional Sequences .
Extended
. of the above three fields) .
Information
. .
3
ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
3
3 E+N 3 Additional Security
Information Format Code 3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3
42
3 3
3
3 E+N+1 Len = J 3 Length of Additional Security
Information 3
3 3
3
CDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD4
3
3 E+N+2 3
3
3 3 Additional Security
Information 3
B 3 E+N+J+1 3 (Zero or more octets)
3
@DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDADDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDY
Table 6.9 Format - Extended Information Field
6.4.3.1 Additional Security Information Format Code
The value of the Additional Security Information Format Code corresponds to a
particular format and meaning for a specific Additional Security Information
field. Each format code is assigned to a specific controlling activity.
Once assigned, this activity becomes the authority for the definition of the
remainder of the Additional Security Information identified by that format
code. A single controlling activity may be responsible for multiple format
codes. However, a particular format code may appear at most once in a PDU.
For each Additional Security Information Format Code an authority is
responsible for, that authority will provide sufficient criteria for
determining whether a CLNP PDU marked with its Format Code should be accepted
or rejected. Whenever possible, this criteria will be Unclassified.
Note: The bit assignments for the Protection Authority flags of the Basic
Portion of the Security Option have no relationship to the "Additional
Security Information Format Code" of this portion.
6.4.3.2 Length of Additional Security Information
This field provides the length, in octets, of the "Additional Security
Information" field immediately following.
6.4.3.3 Additional Security Information
The Additional Security Information field contains the additional security
relevant information specified by the authority identified by the "Additional
Security Information Format Code." The format, length, content, and semantics
of this field are determined by that authority. The minimum length of this
field
is zero.
6.5 USAGE GUIDELINES
43
A PDU is "within the range" if
MIN-LEVEL <= PDU-LEVEL <= MAX-LEVEL
where MIN-LEVEL and MAX-LEVEL are the minimum and maximum security
levels, respectively, that the system is accredited for. The term PDU-LEVEL
refers to the security level of the PDU. In this context, the "security
level" may involve the combination of three factors:
1) classification level
2) protection authorities
3) additional security labelling information as required and defined by
the responsible activity.
The authorities responsible for accrediting a system or collection of systems
are also responsible for determining whether and how these factors interact to
form a security level or security range. A PDU should be accepted for further
processing only if it is within range. Otherwise, the Out-of-Range procedure
described in Paragraph 6.6 should be followed.
6.5.1 Basic Portion of the Security Option
Use of the information contained in the Basic Portion of the Security Option
requires that an end system be aware of:
A. the classification level, or levels, at which it is permitted to
operate, and
B. the protection authorities responsible for its accreditation.
Representation of this configuration information is implementation dependent.
6.5.2 Extended Portion of the Security Option
Use of the Extended Portion of the Security Option requires that the end
system configuration accurately reflects the accredited security parameters
associated with communication via each network interface. Representation of
the security parameters and their binding to specific network interfaces is
implementation dependent.
6.6 OUT-OF-RANGE PROCEDURE
If the Out-Of-Range condition was triggered by:
A. A required, but missing, Security Option or Basic or Extended
Portion of a Security Option, then the PDU should be discarded. In
addition, a CLNP Error Report or other form of reply is not permitted
in this case. However, a local security policy may permit data to be
delivered or a CLNP Error Report PDU to be processed provided a reply
is not sent.
44
B. A PDU whose security level is less than the end system's minimum
security level, then the PDU should be discarded. In addition, a CLNP
Error Report or other form of reply is not permitted in this case.
However, local security policy may permit data to be delivered or a
CLNP Error Report PDU to be processed provided a reply is not sent.
C. A PDU whose security level is greater than the end system's
maximum security level, then:
1. If a CLNP Error Report PDU triggered the Out-of-Range condition,
then no reply is permitted and the PDU should be discarded. A CLNP Error
Report PDU must not be sent in this case.
2. Otherwise, discard the PDU and send a CLNP Error Report PDU to the
originating CLNP entity. The first octet of the Reason for Discard
parameter is set as specified in Table 6.1. The second octet of the
Reason for Discard parameter identifies the Out-of-Range portion of the
Security Option. It should point to the first octet (i.e., the type
indicator) of the Out-of-Range portion. Alternatively, the second octet
can be set to zero. The response is sent at the maximum classification
level of the end system which received the PDU. The protection authority
flags are set to be the intersection of those for which the host is
accredited and those present in the PDU which triggered this response.
Example: PDU = "Secret, GENSER"
End System Level = "Unclassified, GENSER".
Reply = "Unclassified, GENSER".
These are the least restrictive actions permitted by this protocol.
Individual end systems, system administrators, or protection authorities may
impose more stringent restrictions on responses and in some instances may not
permit any response at all to a PDU which is outside the accredited security
range of an end system.
6.7 TRUSTED INTERMEDIARY PROCEDURE
Certain devices in an internetwork may act as intermediaries to validate that
communications between two end systems is authorized. This decision is based
on a combination of knowledge of the end systems and the values in the CLNP
Security Option. [The Blacker Front End (BFE) is one example of such a
trusted device.] These devices may receive CLNP PDUs which are in range for
the intermediate device, but are either not within the accredited range for
the source or the destination. In the former case, the PDU should be treated
as described in Paragraph 6.6. In the latter case, a CLNP Error Report PDU
should be sent to the originating CLNP entity. The first octet of the Reason
for Discard parameter should be set to 1101 0010. This code indicates to the
originating CLNP entity that communication with the end system is
administratively prohibited (refer to Table 6.1). The security range of the
interface on which the reply will be sent determines whether a reply is
allowed and at what security level it should be sent.
45
REFERENCES
National Institute of Standards and Technology
1. NIST Special Publication 500-177, Stable Implementation Agreements
for Open Systems Interconnection Protocols, Version 3. This document can be
purchased from National Technical Information Service (NTIS), U. S. Department
of Commerce, 5285 Port Royal Road, Springfield, VA 22161. For telephone
orders call: (703) 487-4650. This document may also be purchased from the
IEEE Computer Society, Order Department, phone: 1-800-272-6657.
2. FIPS l07, Local Area Networks: Baseband Carrier Sense Multiple
Access with Collision Detection Access Method and Physical Layer
Specifications and Link Layer Protocol, NTIS, U.S. Department of Commerce,
5285 Port Royal Road, Springfield, VA 22l6l.
3. FIPS l00, Interface Between Data Terminal Equipment (DTE) and Data
Circuit-Terminating Equipment (DCE) For Operation With Packet-Switched Data
Communications Networks, NTIS, U.S. Department of Commerce, 5285 Port Royal
Road, Springfield, VA 22l6l.
4. Implementation Agreements Among Participants of OSINET, NBSIR 89-
4158, National Institute of Standards and Technology.
5. Military Supplement to ISO Transport Protocol, National Institute of
Standards and Technology, National Computer Systems Laboratory, ICST/SNA-85-
17, 1985.
6. Implementation Guide for ISO Transport Protocol, National Institute
of Standards and Technology, National Computer Systems Laboratory, ICST/SNA-
85-18, 1985.
7. NIST Special Publication 500-163 Government Open Systems
Interconnection User's Guide. This document can be purchased from the
National Technical Information Service (NTIS), U. S. Department of Commerce,
5285 Port Royal Road, Springfield, VA 22161. For telephone orders call (7023)
487-4650. The NTIS order number is PB90-111212.
8. GOSIP Conformance and Interoperation Testing and Registration,
NCSL/SNA 90-2, 1990.
9. NIST Special Publication 500-182, Message Handling Systems
Implementation Evaluation Guidelines. See [NIST 7] for NTIS ordering
information.
National Communications System
Federal Standard FED-STD 1041, Interface Between Data Terminal Equipment (DTE)
and Data Circuit-Terminating Equipment (DCE) For Operation With Packet-
Switched Data Communications Networks, National Communications System.
46
Institute of Electrical and Electronic Engineers, Inc.
Binary Floating Point Arithmetic (ANS1 Approved), IEEE 754, March 21, 1985,
Institute of Electrical and Electronics Engineers.
The above document may be obtained from: IEEE Standards Office, 345 East 47th
Street, New York, N.Y. l00l7.
Electronic Industries Association
Interface between Data Terminal Equipment and Data Communication Equipment
Employing Serial Binary Data Interchange, EIA-232C.
American National Standards Institute
1. Integrated Services Digital Network - Basic Access Interface for Use
on Metallic Loops for Application on the Network Side of the NT-Layer 1
Specification, ANS T1.601-1988.
2. Integrated Services Digital Network - Basic Access Interface at S and
T Reference Points - Layer 1 Specification, ANS T1.605-1988.
3. Carrier to Customer Installation - DS1 Metallic Interface, ANS T1.
403-1989.
International Organization for Standardization
1. Information Processing Systems - Open Systems Interconnection - Basic
Reference Model, Ref. No. ISO 7498-1984(E).
2. Information Processing Systems - Data Communications - Use of X.25 to
provide the OSI Connection Mode Network Service, IS 8878.
3. Information Processing Systems - Open Systems Interconnection -
Network Service Definition, IS 8348.
4. Information Processing Systems - Open Systems Interconnection -
Addendum to the Network Service Definition Covering Connectionless Data
Transmission, ISO 8348 Addendum 1.
5. Information Processing Systems - Open Systems Interconnection -
Addendum to the Network Service Definition Covering Network Layer Addressing,
ISO 8348 Addendum 2.
6. Information Processing Systems - Open Systems Interconnection -
Internal Organization of the Network Layer, DIS 8648, N3985, Feb., 1986.
7. Information Processing Systems - Open Systems Interconnection -
Protocol for Providing the Connectionless Network Service, IS 8473, N3998,
March, 1986.
8. Information Processing Systems - Open Systems Interconnection - Data
Communication - X.25 Packet Level Protocol for Data Terminal Equipment, ISO
47
8208.
9. 7-bit Coded Character Set for Information Processing Interchange, ISO
646, l973.
10. Information Interchange -- Representation of Local Time
Differentials, ISO 3307, l975.
11. Information Processing Systems - Open Systems Interconnection -
Working Draft - End System to Intermediate System Routing Exchange Protocol
for use in Conjunction with ISO 8473.
12. Information Processing Systems - Open Systems Interconnection -
Transport Service Definition, ISO 8072, l984.
13. Information Processing Systems - Open Systems Interconnection -
Transport Protocol Specification, ISO 8073, l984.
14. Information Processing Systems - Open Systems Interconnection -
Session Service Definition, ISO 8326, l987(E).
15. Information Processing Systems - Open Systems Interconnection -
Session Protocol Specification, ISO 8327, l987(E).
16. Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 1: General Introduction, ISO 8571-1.
17. Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 2: The Virtual Filestore Definition, ISO
8571-2.
18. Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 3: File Service Definition, ISO 8571-3.
19. Information Processing Systems - Open Systems Interconnection - File
Transfer, Access and Management Part 4: File Protocol Specification, ISO
8571-4.
20. Information Processing Systems - Open Systems Interconnection -
Connection-Oriented Presentation Service Definition, ISO 8822.
21. Information Processing Systems - Open Systems Interconnection -
Connection-Oriented Presentation Protocol Specification, ISO 8823.
22. Information Processing Systems - Open Systems Interconnection -
Service Definition for Association Control Service Element - Part 2:
Association Control, ISO 8649.
23. Information Processing Systems - Open Systems Interconnection -
Protocol Specification for Association Control Service Element: Association
Control, ISO 8650.
48
24. Information Processing Systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1), ISO 8824.
25. Information Processing Systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation One
(ASN.1), ISO 8825.
26. Information Processing Systems - Data Communications - High-Level
Data Link Control Procedures - Description of the X.25 LAPB-compatible DTE
Data Link Procedures, ISO 7776.
27. Information Processing Systems - Data Interchange - Structures for
the Identification of Organizations, ISO 6523, 1984.
28. Information Processing Systems - Local Area Networks - Part 2:
Logical
Link Control, DIS 8802/2.
29. Information Processing Systems - Local Area Networks - Part 3:
Carrier Sense Multiple Access With Collision Detection, ISO 8802/3
30. Information Processing Systems - Local Area Networks - Part 4: Token-
passing Bus Success Method and Physical Layer Specifications, ISO 8802/4.
3l. Information Processing Systems - Local Area Networks Part 5: Token
Ring Access Method and Physical Layer Specifications, ISO 8802/5.
32. Information Processing Systems - Open Systems Interconnection -
Virtual Terminal Services - Basic Class, ISO 9040.
33. Information Processing Systems - Open Systems Interconnection -
Virtual Terminal Protocol - Basic Class, ISO 9041.
34. Information Processing Systems - Open Systems Interconnection.
Virtual Terminal Service, Basic Class, ISO 9040, Addendum 1, 1988.
35. Information Processing Systems - Open Systems Interconnection,
Virtual Terminal Protocol, Basic Class, ISO 9041, Addendum 1, 1988.
36. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 1: Introduction and General
Principles, ISO 8613-1, 1988.
37. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 2: Document Structures ISO
8613-2, 1988.
38. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 4: Document Profile, ISO
8613-4, 1988.
49
39. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 5: Office Document
Interchange Format (ODIF), ISO 8613-5, 1988.
40. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 6: Character Content
Architectures, ISO 8613-6, 1988.
41. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 7: Raster Graphics Content
Architectures, ISO 8613-7, 1988.
42. Information Processing - Text and Office Systems-Office-Document
Architecture (ODA) and Interchange Format - Part 8: Geometric Graphics Content
Architectures, ISO 8613-8, 1988.
43. Information Processing Systems - Protocol Identification in the
Network Layer, DTR 9577.
44. Information Processing Systems - End System to Intermediate System
Routing Exchange Protocol for use with ISO 8473, IS 9542.
45. Information Processing Systems - Data Communications - Provision of
the OSI Connection-mode Network Service, by Packet Mode Terminal Equipment
connected to an Integrated Services Digital Network (ISDN), DIS 9574.
46. Information Processing Systems - Transport Service Definition
covering Connectionless Mode Transmission, ISO 8072/ADD.
47. Information Processing Systems - Protocol for Providing the
Connectionless Mode Transport Service, ISO 8602.
48. Information Processing Systems - Telecommunications and information
exchange between systems - OSI Routing Framework, ISO/TR 9575.
49. Information Processing Systems Telecommunications and information
exchange between systems - Intermediate systems to Intermediate system Intra-
Domain routing exchange protocol for use in conjunction with the protocol for
providing the Connectionless mode Network Service ISO/IEC JTC1/SC6 DP 10589.
The above documents may be obtained from:
ANSI Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
International Telephone and Telegraph Consultative Committee
1. CCITT Recommendation X.25-1984, Interface Between Data Terminal
Equipment (DTE) and Data Circuit-Terminating Equipment (DCE) for Terminals
Operating in the Packet Mode on Public Data Networks.
50
2. CCITT Recommendation X.400, (Red Book, 1984), Message Handling
Systems: System Model-Service Elements.
3. CCITT Recommendation X.40l, (Red Book, 1984), Message Handling
Systems: Basic Service Elements and Optional User Facilities.
4. CCITT Recommendation X.408, (Red Book, 1984), Message Handling
Systems: Encoded Information Type Conversion Rules.
5. CCITT Recommendation X.409, (Red Book, 1984), Message Handling
Systems: Presentation Transfer Syntax and Notation.
6. CCITT Recommendation X.4l0, (Red Book, 1984), Message Handling
Systems: Remote Operations and Reliable Transfer Server.
7. CCITT Recommendation X.4ll, (Red Book, 1984), Message Handling
Systems: Message Transfer Layer.
8. CCITT Recommendation X.420, (Red Book, 1984), Message Handling
Systems: Interpersonal Messaging User Agent Layer.
9. CCITT Recommendation X.430, (Red Book, 1984), Message Handling
Systems: Access Protocol for Teletex Terminals.
10. CCITT Recommendation X.214, (Red Book, 1984), Transport Service
Definition for Open Systems Interconnection for CCITT Applications.
11. CCITT Recommendation X.224, (Red Book, 1984), Transport Protocol
Specification for Open Systems Interconnection for CCITT Applications.
12. CCITT Recommendation X.215 (Red Book, 1984), Session Service
Definition for Open Systems Interconnection for CCITT Applications.
13. CCITT Recommendation X.225 (Red Book, 1984), Session Protocol
Specification for Open Systems Interconnection for CCITT Applications.
14. CCITT Recommendation X.400 - Series Implementor's Guide (Version 6,
November 1987).
15. CCITT Recommendation X.121 (Red Book, 1985), International
Numbering Plan for Public Data Networks.
16. CCITT Recommendation V.35 - Data Transmission at 48 kilobits/second
using 60-108 kHz group band circuits.
17. CCITT Recommendation T.410 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Overview
18. CCITT Recommendation T.411 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Introduction and General
Principles
51
19. CCITT Recommendation T.412 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Document Structures
20. CCITT Recommendation T.414 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Document Profile
21. CCITT Recommendation T.415 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Document Interchange Format (ODIF)
22. CCITT Recommendation T.416 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Character Content Architectures
23. CCITT Recommendation T.417 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Raster Graphics Content
Architectures.
24. CCITT Recommendation T.418 (Blue Book, 1988) Open Document
Architecture (ODA) and Interchange Format - Geometric Graphics Content
Architectures.
25. CCITT Recommendation Q.921 (I.441) (Blue Book, 1988) ISDN User-
Network Interface Data Link Layer Specification.
26. CCITT Recommendation Q.931 (I.451) (Blue Book, 1988) ISDN User-
Network Interface Layer 3 Specification for Basic Call Control.
27. CCITT Recommendation X.31 (Blue Book, 1988) Support of Packet Mode
Terminal Equipment by an ISDN.
The above documents may be obtained from: International Telecommunications
Union, Place des Nations, CH l2ll, Geneve 20 SWITZERLAND.
Miscellaneous
1. Manufacturing Automation Protocol
2. Technical and Office Protocols, Specification Version 3.0
For copies of the two documents listed above, contact: Corporation for Open
Systems, 1750 Old Meadow Road, McLean, VA 22102-4306.
52
FOREWORD TO THE APPENDICES
Appendices 1-5 describe U. S. Government advanced requirements for which
adequate specifications have yet to be developed. This section, revised by
the GOSIP Advanced Requirements Group, gives an updated and more complete
summary of protocols planned for inclusion in future versions of the document.
Each summary states the requirements for including the protocol in GOSIP and a
plan of work to meet those requirements.
New versions of GOSIP will be issued no more frequently than once a year and
the comments of manufacturers, government agencies and the public will be
solicited before each new version is released.
The following protocols are candidates for inclusion in Version 3 of GOSIP.
1. Directory Services
2. Optional Class 2 Transport Protocol
3. CGM
4. Virtual Terminal (X3, page, scroll profiles)
5. MHS extensions based on 1988 CCITT Recommendations
6. FTAM extensions
7. FDDI
8. Network Management (Also the subject of a separate FIPS.)
9. Optional Security Enhancements
10. SGML
11. Manufacturing Message Specification
12. Intra-domain Dynamic Routing
13. EDI
The following protocols are candidates for inclusion in Version 4 of GOSIP.
1. Transaction Processing
2. Remote Database Access
3. Additional Optional Security Enhancements
4. Additional Network Management Functions
5. Inter-domain Dynamic Routing
The purpose of Appendices 1-5 is to assist federal agencies in planning
decisions relating to the acquisition of implementations of OSI protocols.
Appendix 6 specifies a list of acronyms.
These appendices are not part of the Federal Information Processing Standard.
53
APPENDIX 1. SECURITY
1.1 BACKGROUND
The Open Systems Interconnection Security Architecture is now an International
Standard (IS 7498/2). This document provides a general architecture that may
be used in implementing security services in OSI networks. Five primary
security services are specified in the architecture as well as the OSI layers
at which security services could be offered. The document also discusses many
security mechanisms which can be used in providing the services.
The OSI Security Architecture provides a basis for developing security but it
does not provide specifications for implementing security. A significant
level of effort is required before specifications for security are available
that can be used in standards. This appendix addresses the need for security
standards, the status of standards being developed and plans for developing
additional required standards.
While the term "Open Systems" implies that users of such systems intend that
the systems be open to others, the users always want to provide access to such
systems only to authorized users for authorized purposes. Systems that
process sensitive and valuable data, especially classified data, must be
protected from a wide variety of threats. Vulnerabilities of open systems
include unauthorized access and denial of service. Vulnerabilities of data in
open systems include unauthorized disclosure, modification and destruction,
both accidentally and intentionally.
Computer programs designed to obtain, modify or destroy data or to simply deny
service to authorized users are a threat to networks of computers. Such a
program is often called a Virus or a Worm. Computers which allow programs to
be executed that have been imported from an external source, either via the
network or through a storage medium, may be vulnerable to such programs.
Users should always have back-up copies of valuable data in an off-line
storage facility in case the on-line data is modified or destroyed. Trusted
systems with isolation and controlled sharing mechanisms should be used to
minimize the threat of a Virus or a Worm.
Security is an option in GOSIP. As such, security services may be provided at
one or more of the layers 2, 3, 4, 6 and 7. The Appendix 1 figure depicts
placement of security in the overall profile by augmenting Figure 3.2 with
optional security in order to form the Government OSI security architecture.
The security architecture described here suggests a range of choices for
security services and their placement. It is expected that a subset of these
services and layers will adequately satisfy specific security requirements.
Because security inherently restricts access and if applied at different
layers will prohibit interoperability, it is the responsibility of an
acquisition authority to insure that the security options chosen provide the
desired interoperability as well as the required security.
1.2 REQUIREMENTS
54
The primary security services that are defined in the OSI security
architecture are authentication, access control, confidentiality, integrity
and non-repudiation. These are defined in detail in IS 7498/2 and are
summarized, with simple examples given, below:
*Data confidentiality services protect against unauthorized disclosure.
Protecting the details of an attempted corporate takeover is an example of the
need for confidentiality.
*Data integrity services protect against unauthorized modification,
insertion and deletion. Electronic funds transfer between banks requires
protection against modification of the information.
*Authentication services verify the identity of communicating peer entities
and the source of data. Owners of bank accounts require assurance that money
will be withdrawn only by the owner.
*Access control services allow only authorized communication and system
access. Only financial officers are authorized access to a company's
financial plans.
*Non-repudiation with proof of origin provides to the recipient proof of the
origin of data and protects against any attempt by the originator to falsely
deny sending the data or its contents. Non-repudiation with proof of origin
can be used to prove to a judge that a person signed a contract.
Requirements have been identified for government applications for all five of
these services, especially the first four. Authentication, confidentiality
and integrity services may be implemented in layers 3, 4 and 7 of the OSI
architecture while access control and non-repudiation services are offered
only at layer 7. Applications, such as Electronic Message Handling Systems,
can be provided all security services at layer 7. Providing security at
either layer 3 or 4 is generally required but not at both layers. The
selection of security services at specific layers must be made by the
acquisition authority and depend on the benefits derived and the costs
encountered.
1.3 STATUS
Interoperability standards are required for security at layers 2, 3, 4, and 7
of the OSI architecture. Specifications for security at layers 3 and 4 as
well as for Electronic Message Handling Systems have been prepared within the
Secure Data Network System project. (See NISTIR 90-4250) Specifications for
security at layer 2 are being drafted by the IEEE 802.10 LAN Security Working
Group developing a Standard for Interoperable LAN Security (SILS).
Specifications for authentication of data have been issued in standards by the
National Institute of Standards and Technology (formerly the National Bureau
of Standards) (FIPS 113) and ANSI (ANSI X9.9). Specifications for key
management protocols have been issued in a standard by ANSI (X9.17).
The OSI Implementors' Workshop Special Interest Group in Security is reviewing
55
the specifications of SDNS (See NISTIRs 90-4259 and 90-4262) as they become
public. It is also reviewing proposals on security management. It has
reviewed several security frameworks and architectures that may be used for
future security standards development.
1.4 PLANS FOR ACHIEVEMENT
The specifications and standards referenced above will be reviewed by the
security staff of NIST, by the members of the OSI Implementors Workshop
Security SIG and by members of the GOSIP committee for inclusion in one or
more of the following: Federal Information Processing Standards; ANSI
Standards; and ISO Standards. The following outlines the plans for satisfying
the requirements for security in OSI, the development of public specifications
and the development of standards incorporating the specifications.
1.4.1 OSI Security Architecture
The OSI Security Architecture (IS 7498/2) was adopted as an International
Standard in 1988. This document is included in the Implementors Agreements as
being the basis for all OSI security development. No further work is needed on
this document at this time.
1.4.2 OSI Security Frameworks
A set of security frameworks of specific information processing applications
are planned by the ISO/IEC/JTC 1/SC21/WG1 Security Group. An authentication
framework is an example of such a framework. The Security SIG will continue
to review these frameworks for adoption in the Implementors Agreements or to
develop frameworks that are needed but are not in development in ISO.
1.4.3 Data Link Layer Security
An IEEE Standard for Interoperable LAN Security is being developed over the
next 1-2 years by the IEEE 802.10 LAN Security Working Group. A Standard for
Interoperable LAN Security could be ready in 1990 for consideration by the OSI
Implementors Workshop Security SIG.
1.4.4 Network Layer Security
The SDNS Network Layer Security protocol document (SP3) is available for
public use. This protocol was presented to ANSI in 1989. The protocol
encapsulates the T-PDUs just like the Transport Layer security protocol except
that it can also add network addresses to the protocol header for network
routing. The protocol may be implemented in intermediate gateway systems as
well as end systems. A Network Layer Security protocol standard could be
ready in 1991.
1.4.5 Transport Layer Security
56
The SDNS Transport Layer Security protocol document (SP4) is available for
public use and a FIPS is being proposed based on this work. This protocol was
presented to ANSI and ISO in 1989. The protocol encapsulates the Transport
Protocol Data Units, adds an integrity code if integrity is desired, encrypts
the entire T-PDU if confidentiality is desired, and then puts the result in a
SE T-PDU (SE stands for security envelope or secure encapsulation). A
receiver that has the correct cryptographic key can decrypt the SE T-PDU,
verify its integrity and then process the resulting T-PDU. A Transport Layer
Security protocol standard could be ready in 1991.
1.4.6 Electronic Message Handling System Security
The X.400 Electronic Message Handling System security recommendations and the
DARPA Mail Security RFC 1040 are available for public use. The SDNS Message
Handling Security protocol specifications are also available for public use.
A standard format for secure electronic messages could be ready in 1992.
1.4.7 Cryptographic Key Management Protocols
The ANSI X9.17 Key Management Protocol, which is based on private key
cryptographic algorithms, and several public key management protocols are
being reviewed by the NIST security staff. A key management protocol based on
public key cryptographic algorithms could be ready in 1993 for implementation.
57
Figure A.1 Framework for OSI Security
58
APPENDIX 2. SYSTEM AND ARCHITECTURE
2.1 Network Management
OSI management functionality supports the location and correction of faults,
the establishment and adjustment of configurations, the measurement and tuning
of performance, the management of security, and collection and reporting of
billing and accounting information. Such functionality is in end systems
(hosts), intermediate systems (routers), and other network elements (e.g.,
network services, bridges, switches, modems, and multiplexors). The primary
goal for a Federal Government network management specification is to create
the ability for managing multi-vendor computer and telecommunications networks
remotely without undue use of proprietary management protocols. The scope of
a network management specification for use by the U.S. Government will include
protocols for exchanging management information and the definition and format
of information to be exchanged.
Note: The primary vehicle for this specification will be a Federal
Information Processing Standard (FIPS). This FIPS will reference GOSIP and
will be referenced by GOSIP. (The FIPS is discussed further below under
"Plan".)
Requirements
Requirements for OSI network management are described in detail within a NIST
report, Management of Networks Based on Open Systems Interconnection (OSI)
Standards: Functional Requirements and Analysis (NIST Special Publication 500-
175, November 1989). Requirements exist for an overall management
architectural framework model including fault, accounting, configuration,
security, and performance management services.
Status
The OSI management standards are in an intermediate stage of their development
and are progressing rapidly. Key areas for management standards are
architecture, protocols, system management functions, and the structure of
management information. The following table lists the latest available ISO
schedule for management standards approved at the Sixth SC 21/WG 4 Meeting in
Florence, October 31 - November 9, 1989.
TARGET
DATES
DP DIS IS
Management Architecture
Management Framework 9/86 6/87 10/88
Systems Management Overview 7/90
4/91
Management Protocol
Common Management Information Service
59
1/90
Addendum 1: CancelGet 9/89
7/90
Addendum 2: Add/Remove 9/89
7/90
Common Management Information Protocol
1/90
Addendum 1: CancelGet 9/89
7/90
Addendum 2: Add/Remove 9/89
7/90
Structure of Management Information
Part 1: Management Information Model 5/89
1/90 1/91
Part 2: Definition of Management 7/90
4/91
Information
Part 4: Guidelines for the Definition 11/89
1/91 1/92
of Managed Objects
TARGET DATES
DP DIS IS
Management Functions
Configuration Management
Systems Management - Part 1:
7/90 7/91
Object Management Function
Systems Management - Part 2: 7/90
7/91
State Management Function
Systems Management - Part 3:
7/90 7/91
Relationship Management Function
Fault Management
Systems Management - Part 4:
7/90 7/91
Alarm Reporting Function
Systems Management - Part 5:
7/90 7/91
Event Report Management Function
Systems Management - Part *: 7/90
4/91 4/92
Confidence and Diagnostic Testing Function
Systems Management - Part 6: 11/89
7/90 7/91
Log Control Function
Security Management
Systems Management - Part 7: 11/89 7/90
7/91
Security Alarm Reporting Function
60
Systems Management - Part *: 7/90 4/91
4/92
Security Audit Trail Function
Accounting Management
Systems Management - Part *: 7/90 4/91
4/92
Accounting Metering Function
Performance Management
Systems Management - Part *: 7/90 4/91
4/92
Workload Monitoring Function
Systems Management - Part *: 7/90
4/91 4/92
Measurement Summarization Function
As can be seen from the above schedule, there are several important standards
that have now reached, or soon will reach, International Standard (IS) status.
However, many others are still two years away from IS. Still others that are
planned, e.g., Software Management (including "down-line load"), have not yet
been added to the schedule. It is important to note that the Draft
International Standards (DISs) scheduled to be available by the end of 1990
comprise a subset that will make it possible for vendors to build useful
systems to solve many immediate network management problems.
Standards for the specification of managed objects are now being developed by
ISO, ANSI, CCITT, and the IEEE, as well as by the Internet Engineering Task
Force of the Internet Activities Board (for management of TCP/IP oriented
networks). In general, full specifications and standards from these
organizations are expected to lag the above SC21/WG4 management schedule by
more than a year.
Another important aspect of network management standards activity is the
development of implementation agreements (IAs). The network management SIG of
the NIST OIW is developing IAs based upon the emerging network management
standards. These agreements are being developed according to a phased
approach that aligns with the ISO standards as they progress from DP to IS.
The OSI/NM Forum is also developing a set of agreements (termed
specifications) for network management. These agreements, based on earlier
ISO documents and original Forum work, are to be used as a basis for Forum-
sponsored interoperable management demonstrations planned for 1990 and beyond.
Both formal and informal liaison between the NMSIG of the OIW and the NM Forum
has proved mutually beneficial in advancing each set of agreements, including
identifying and correcting errors and omissions.
Plan
There is an urgent need today for products to manage multi-vendor computer and
telecommunications networks. The U.S. Government requires initial network
management specifications that provide a useful subset of the full OSI
management functionality. It is desirable to specify the initial subset in
such a way that it is easy to add other capabilities to reach the full set of
management functionality. Such additional functionality may include the
61
management of future technologies such as ISDN and FDDI, and may include new
management services such as software management and time management.
The U.S. Government intends to propose an initial FIPS based on the OIW stable
network management IAs. The OIW will include at most the following in its
agreements to be completed in 1990 (from phase one of the OIW IAs):
Management Functions:
Object Management, State Management, Relationship Management, Error
Reporting and Event Control
Management Information:
Information Model, Naming, Guidelines and Template for Defining Managed
Objects
Management Communication:
CMIS/P, Association Policies, and Services Required
Management Objects:
Support Objects required for above and selected Managed Object
Definitions under development by the OSI MIB WG
Conformance Criteria:
TBD depending on the progress of relevant ISO documents.
It is planned that the initial network management FIPS will be based on
portions of the above phase one stable agreements. The FIPS will include
specifications for a management protocol based on OIW IAs for CMIS/CMIP, and
it will include management function specifications based on the OIW IAs.
Also, the FIPS will include a library of management objects (MIL). In
addition, other portions of the agreements may be cited in the FIPS.
GOSIP profiles will be cited in the FIPS to specify the protocol stack upon
which management information will be conveyed and to include OSI applications
suitable to support management of networks.
Once an initial management FIPS has been established, portions of future GOSIP
versions may reference management FIPS as appropriate. For example, to
specify management of network end system (host) computers, GOSIP might
reference the Network Management FIPS sections on the use of CMIS/CMIP as a
method for conveying information and sections on system management functions
for specific management services. GOSIP might also reference the management
FIPS for appropriate managed object definitions. Likewise for the management
of network routers, GOSIP might reference the FIPS for use of CMIS/CMIP,
management functions and managed object definitions.
These are possible initial examples. As both the FIPS and GOSIP mature, GOSIP
will likely make many additional references to newer versions of the
management FIPS. (And the FIPS can be expected to additionally reference
newer versions of GOSIP as well.)
2.2 REGISTRATION
62
OSI Registration procedures are the key to creating globally unique
identifiers for OSI objects. Most OSI objects are identified via a
hierarchically structured label. Specific procedures must be established to
ensure that GOSIP identifiers fit within an internationally recognized plan
and uniquely identify GOSIP objects.
Requirement
Procedures are required for the registration of OSI objects, such as
organization numbers and names. The specific complete list of objects is
subject to further study and is likely to evolve over time, as directory
services are adopted. For the first version of GOSIP, procedures were
required for registration of organization identifiers for use in NSAPs, labels
for electronic mail private body parts, and organization names for electronic
mail addresses. The third version of GOSIP will require extending the
procedures to include directory distinguished names. An immediate requirement
not specific to GOSIP is registration procedures for objects defined in the
OSI Implementor's Agreements.
Status
A standard for registration procedures is under development in ISO. The NIST
is already maintaining a small registration service for OSINET members. The
NIST has secured three international code designators (ICDs) as follows: 1)
four (4) allocated to OSINET and the NIST/OSI Implementor's Workshop; 2) five
(5) allocated to the U. S. Government, and 3) fourteen (14) allocated to the
OSI Implementors' Workshop (OIW).
Plan
The NIST is updating the GOSIP User's Guide for publication with Version 2 of
GOSIP. One section of the guide will detail GOSIP registration procedures. A
registration SIG in the NIST OSI Implementors' Workshop has identified objects
requiring registration and established detailed procedures for registering the
objects.
2.3 ADDRESSING
GOSIP network addressing is limited to defining NSAPs. The existing
assumption is that NSAPs will be retrievable from a directory service and that
each NSAP will address a single host. Nothing within GOSIP is designed to
preclude multi-homed or mobile end systems. The problem is that no routing
protocol exists to deal with mobile hosts at the speed required for some
applications. At the present time, there is no definition for the semantics
and syntax of multi-cast addressing within the network layer.
Requirement
Multi-cast addressing is required to support operation on broadcast networks
with connectionless protocols.
Status
63
No work is underway in this area.
Plan
Study inclusion of multi-cast NSAPs for operation over broadcast networks
(e.g., local networks) in conjunction with connectionless transport, network,
and data link protocols.
64
APPENDIX 3. UPPER LAYERS
3.1 X.400 EXTENSIONS
Message Handling System specifications in Version 2 of GOSIP are based on the
1984 CCITT Recommendations. GOSIP MHS extensions will be based on the CCITT
1988 Recommendations. These recommendations provide new capabilities
including security, delivery to a physical delivery service, use of a
directory service, delivery to a message store, and an OSI architecture which
includes ACSE and the Presentation layer.
Requirements
A requirement exists for MHS security features such as message originator
authentication, checks against unauthorized disclosure and verification of
content integrity. It is also highly desirable to have message store delivery
which will allow personal computers without full User Agent functionality to
have access to MHS services. The DOD requires that military precedence levels
and preemption features be incorporated into the Message Handling Systems
standard and that a method be developed of passing this information to the
connectionless network layer protocol for processing.
Status
A. Standards - The 1988 CCITT MHS Recommendations were formally
approved in late 1988.
B. Implementors' Agreements - In 1989, the MHS SIG issued implementors'
agreements which provided a minimally conformant 1988 Message Handling System.
These implementors' agreements do not include significant additional user
services, but allow interworking with implementations conforming to the NIST
Stable Implementation Agreements for CCITT 1984 X.400-based Message Handling
Systems and provide a firm basis for the introduction of further 1988 services
and features. Further implementors' agreements based on CCITT 1988 X.400 are
expected in 1990.
Plan
As an interim measure, NSA and NIST should determine whether the SDNS method
of sending security information in a new special-purpose User Agent satisfies
all GOSIP advanced security requirements for electronic mail. This approach
would allow security information to be sent on Message Handling Systems
implemented according to the CCITT 1984 Recommendations. However, the new
User Agent would not be based on an international standard.
There already exists the capability of sending and receiving X.400 mail from a
personal computer attached to a host by using terminal emulation software.
The User Agent is co-located with the MTA and the terminal interface is a
local matter. The GOSIP Advanced Requirements Group plans to investigate to
what extent this architecture satisfies current government requirements.
65
There is also a proposal to include a message store (i.e., standard remote
User Agent) capability in a future MHS implementors' agreement. A message
store would provide a standard software package with standard error recovery.
When implementors' agreements for message store are adopted, the functionality
in those agreements will be incorporated into GOSIP.
The DoD requirement for expansion of precedence levels will be forwarded to
the CCITT committee on Message Handling Systems. The GOSIP Advanced
Requirements Group will request the NIST/OSI Implementors' Workshop to
determine how Application-level precedents can be passed to the lower layers
for processing.
3.2 FTAM (FILE TRANSFER, ACCESS AND MANAGEMENT)
The File Transfer, Access and Management protocol and service allow users on
different networks to communicate about files (and transfer files) without
requiring that one user know the detailed file characteristics of the other
user. A generic file organization is defined for communication; elements of
this virtual file model are mapped to corresponding elements of the local file
system. A comprehensive set of file attributes and file activity attributes
are defined; in addition, a large number of actions is possible on a wide
variety of file types.
Requirement
Implementation profiles are defined for user requirements as follows: simple
file transfer, positional file transfer, full file transfer, simple file
access, full file access, and management. Each implementation profile
contains a different combination of document types, attributes and service
classes. An FTAM implementation for the GOSIP should require support of the
positional file transfer (which includes simple file transfer), simple file
access and management implementation profiles. Future versions of GOSIP
should include overlapped access, filestore management (including file
directory query capability), error recovery capability, concurrency control
capability, and File Access Data Unit (FADU) locking capability.
Status
A. Standards - FTAM has been released as an International Standard from
ISO; currently FTAM comprises five parts: general introduction, virtual
filestore definition, file service definition, file protocol specification,
and protocol information conformance statement proforma. There are two
prospective addenda which are overlapped access and filestore management.
Filestore management should reach IS status in late 1991, and overlapped
access should reach IS status in early 1992.
B. Implementors' Agreements - FTAM Phase 2 (based on IS text) was
completed as of December 1988, and maintained since then with the inclusion of
several errata. This agreement provides for all core services defined in the
FTAM standard except for restart, recovery and concurrency. Facilities for
66
full file transfer and record-level access are provided; three different FTAM,
and four different NIST document types are defined. FTAM Phase 2 is included
in Version 3 of the workshop agreements, available after December 1989. FTAM
Phase 3 provides restart, recovery and concurrency capabilities, and enlarges
on the set of document types currently defined. FTAM Phase 3 is complete as
of March 1990. FTAM Phase 2 Agreements are upwardly compatible to FTAM Phase
3 Agreements at the intersection of their functional capabilities.
Plan
FTAM Phase 2 is currently included in versions 1 and 2 of GOSIP; reference is
made to the Phase 2 FTAM (based on IS) as it appears in the workshop
agreements. A file directory service capability is planned for in a future
version of GOSIP; it is also anticipated that a number of new document types
will be included in the future. Possibly, full file transfer and full file
access implementation profiles will be mandated. Recovery, restart and
concurrency control capabilities may also be required. It is anticipated that
Version 3 of GOSIP will mandate the FTAM Phase 3 specification from the
Workshop Agreements. NIST personnel will work with the FTAM Special Interest
Group at the NIST/OSI Implementors' Workshop to expedite the development of
implementation agreements and to insure that government requirements are
included.
3.3 VIRTUAL TERMINAL
The Basic Class Virtual Terminal Protocol allows terminals and hosts on
different networks to communicate without requiring that one side know the
terminal characteristics handled by the other side. A generic set of terminal
characteristics is defined for communication which is mapped to local terminal
characteristics for display. An addendum to Basic Class VT provides a forms
mode capability.
Requirement
The service options to be selected include type of negotiation and the VT
profiles to be specified. Additional implementation profiles for GOSIP will
include profiles for page and scroll terminals in addition to the existing
TELNET and forms profiles. No negotiation capability is required.
Status
A. Standards - All comments on Basic Class VT and on addendum 1 (forms)
have been resolved and the service and protocol documents for Basic Class and
the addendum have been merged.
B. Implementors' Agreements - Stable agreements were completed for the
TELNET, Transparent, and Forms profiles in December 1988. Stable Agreements
for the X3 profile were completed in December 1989.
Plan
67
Version 3 of GOSIP is expected to include the X3, scroll and page profiles.
Additional options may be added to the TELNET profile. NIST personnel will
work with the VT Special Interest Group in the NIST/OSI Implementors' Workshop
to expedite the development of implementation agreements and to insure that
government requirements are included.
3.4 THE DIRECTORY
A directory is a collection of attributes (i.e., information) about, and
relations between, a named set of addressable objects within a specific
context. A directory can be viewed as a data base containing instances of
record types. The most typical relationship between a directory user and the
directory itself is that of an information user and an information provider.
The user supplies an unambiguous or ambiguous key to the directory, and the
directory returns the information labeled by the key. The directory user may
filter the available information to access only the most essential fields.
Requirement
The requirements for a GOSIP directory service are much too complicated and
voluminous to include here. The NIST has developed a separate report
specifying the requirements. From the complete requirement set, the NIST has
identified an initial subset for inclusion into GOSIP. In summary, for the
initial directory, requirements include: 1) functions provided by the DoD
"whois" service (a name to data record mapping), and the DoD domain name
service (host name to network address mapping), 2) service name to T-selector,
S-selector, and P-selector mapping, 3) inclusion of a host's capabilities
within the host directory entry, and 4) the ability to resolve mailing list
names into a set of electronic mail addresses. For the initial GOSIP
directory, access control, simple authentication, and replication are also
required.
Status
The Directory is an IS in ISO (ISO 9594) and has been issued by CCITT as the
X.500 series of Recommendations. Workshop Agreements exist based on these
documents. ISO and CCITT are jointly developing extensions to the current
standard in areas where it is known to be deficient, such as access control,
replication, and the information model. Additional implementation agreements
are needed to cover the extensions.
Plan
The plan is to improve the directory implementor agreements as necessary and
to get needed changes into the ISO and X.500 versions of the standard to
support the initial GOSIP requirements. These goals should be accomplished in
1991 and 1992 so that an initial directory specification can be included in a
subsequent version of GOSIP.
3.5 REMOTE DATABASE ACCESS
68
Remote Database Access (RDA) allows the interconnection of database
applications among heterogeneous environments by providing standard OSI
Application layer protocols to establish a remote connection between a
database client and a database server. The client is acting on behalf of an
application program while the server is interfacing to a process that controls
data transfers to and from a database.
Requirement
There is a strong requirement to share information among Database Management
Systems from different vendors which are widespread in both government and
industry. The Remote Database Access protocol allows that data sharing by
providing a neutral "language" by which heterogeneous systems can communicate.
An extension of the above requirement is the need for distributed database
capability. This will be achieved in the long-term by extending the existing
RDA model, and through RDA's harmonization with the Transaction Processing
protocol.
Status
The RDA standard is specified in two documents, a generic RDA for arbitrary
database connection and an SQL specialization for connecting databases
conforming to the standard database language SQL. Both the generic RDA
standard and the RDA specialization for SQL include functionality required by
Federal agencies.
The generic RDA standard reached DP status in 1987 and is expected to reach
DIS status in 1990. The RDA specialization for SQL is also expected to reach
DP status in 1990. Final adoption of ISO International Standards for both
documents is expected in 1992.
Plan
Vendors, particularly SQL vendors, plan to have implementations conforming to
the ISO International Standard available at the earliest possible time. An
RDA SIG was formed within the NIST OSI Implementors' Workshop in 1989 to
assist in this process.
3.6 TRANSACTION PROCESSING
Requirement
The specific requirements within the U. S. Government for transaction
processing are still under investigation.
Status
Current plans are for Transaction Processing to move to IS status in 1990 or
in 1991.
Plan
69
NIST is working with Federal agencies to determine transaction processing
requirements and is representing the interests of Federal agencies in the
national and international standards committees. The first step is for the
federal agencies that have transaction processing requirements to become
knowledgeable about the TP services specified in the evolving TP standards
documents and to determine whether these services meet the needs of their
organization. NIST is willing to assist other federal agencies in the
process.
A Transaction Processing SIG has been formed within the NIST/OSI Implementors'
Workshop.
3.7 ELECTRONIC DATA INTERCHANGE
Electronic Data Interchange (EDI) describes the rules and procedures that
allow computers to send and receive business information in electronic form.
Business information includes the full range of information associated with
buyer/seller relationships (e.g., invoices, Customs declarations, shipping
notices, purchase orders).
Requirements
The Office of Management and Budget is proposing to issue a guidance document
that states that Federal agencies shall, to the maximum extent practicable,
make use of Electronic Data Interchange with supporting GOSIP
telecommunications networks for the processing of business-related
transactions.
Status
A. Standards - 1) ANSI committee X12 has developed and is developing
standard formats for business-related messages. There is also an ISO standard
(IS 9735) for Electronic Data for Administration, Commerce and Transportation
(EDIFACT). The JTC1 special working group on EDI is developing a conceptual
model for Electronic Data Interchange. 2) CCITT Study Group VII established
a Rapporteur Group to work on a solution on how to perform EDI using Message
Handling Systems. The group completed work on a set of recommendations in
June 1990. This group established a new content type for EDI and a
corresponding content protocol (currently designated PEDI). PEDI will provide
service elements and heading fields for EDI similar to those provided by P2
for interpersonal messages.
B. Implementors' Agreements - The NIST Workshop Agreements currently
contains basic guidelines for adopting 1984 X.400 as the interim data
transfer mechanism between EDI applications.
Plan
If products based on the CCITT Interim Recommendations are available in 1992,
70
EDI will be included in Version 3 of GOSIP; Otherwise, EDI is scheduled for
inclusion in Version 4 of GOSIP.
3.8 MMS SERVICES
The Manufacturing Message Specification (MMS) application can be used to
obtain and/or manipulate objects related to a manufacturing environment.
These objects include, but are not limited to, variables semaphores, data
types, and journals. Although MMS was designed for a manufacturing
environment, these objects have applicability outside of manufacturing.
Requirements
Although the government is not a primary manufacturer, MMS has usefulness in
the acquisition of point of measurement quality data, in military depots at
the Department of Energy, and Department of Defense sites. Additionally, the
Deep Space Network Data Systems group of the Jet Propulsion Laboratory is
investigating the use of MMS for on-board control and telemetry.
Status
MMS is currently at the IS level in ISO and has implementors' agreements ready
for inclusion in the NIST/OSI Stable Implementor Agreements in 1990.
There are implementations available based upon DIS-9506(MMS) which are already
installed. A mechanism for backwards compatibility has been agreed and is
ready to progress into the Stable Agreements document. Work is ongoing to
establish agreements on all 86 services that are contained within MMS.
Plan
The plan is to augment and improve the MMS implementors' agreements as
required. Additionally, abstract test cases will be reviewed and generated as
necessary to further refine the definition of MMS conformance. This work is
ongoing with anticipated completion of a subset of services in 1990 so that
MMS can be included in Version 3 of GOSIP.
3.9 INFORMATION RETRIEVAL
Information retrieval supports the open interconnection of database users with
database providers by specifying an OSI application layer protocol for
intersystem search and retrieval of records from a remote bibliographic
database.
Requirement
Information retrieval functionality is required by Federal agencies which need
to retrieve information from remote bibliographic databases.
Status
71
The OSI Information Retrieval service and protocol is specified in the ANSI
standard: Z39.50-1988 - Information Retrieval Service Definition and Protocols
Specification for Library Applications. A corresponding ISO standard (ISO
10162 and 10163: Search and Retrieve Service Definition and Protocol
Specification) has reached DIS status. Final adoption as international
standards is expected by early 1991.
Plan
Vendors are now developing implementations conforming to Z39.50. A Z39.50
implementor's group has been formed, represented by more than 20 companies.
Options will be investigated to include bibliographic searching within GOSIP.
Agencies are encouraged to bring forth other information retrieval
requirements.
72
APPENDIX 4. EXCHANGE FORMATS
The following standards are not OSI standards, but they provide services
required by Federal agencies and the format information that they specify can
be transferred by OSI Application layer protocols, such as FTAM and MHS.
4.1 ODA EXTENSIONS
ODA allows for the interchange of compound documents (documents containing
text, facsimile, and graphics) which have been generated by diverse types of
office products, including word processors and desktop publishing systems.
Interchange of ODA documents may be by means of data communications or the
exchange of storage media. ODA documents may be in processable form (to allow
further processing such as editing or reformatting) or in final form (to allow
presentation as intended by the originator) or in both forms. The key concept
in the document architecture is that of structure -- the division and repeated
subdivision of the content of a document into increasingly smaller parts
called objects. Two structures are defined by ODA: these are logical
structure (contents are divided based on meaning, e.g., chapters, sections,
paragraphs) and layout structure (contents are divided based on form, e.g.,
pages, blocks).
Requirement
A Document Application Profile (DAP) specifies the constraints on document
structure and content according to the rules of the ODA standard. Different
DAPs can be created that apply to different classes of document. As
extensions to ODA are made, they will be incorporated into the DAPs specified
in the Workshop Agreements.
Status
A. Standards - ODA is an international standard; however, several areas
within ODA are currently being studied, enhanced and/or extended. The primary
emphasis on extensions includes new content architectures (such as
spreadsheets and audio) and new features such as variant of styles, complex
tables, alternative representation, computed data in documents, and an
interface to EDI. Several addenda are planned to cover these extensions.
B. Implementors' Agreements - The ODA SIG will examine extensions as they
are developed to determine whether or not to incorporate such extensions in
DAPs.
Plan
The plan is to contribute to the work on extensions to ODA through the
Workshop by informing standards groups of deficiencies and inadequacies of the
standard and to incorporate developed extensions into applicable DAPs when
these extensions are mature. GOSIP will reference applicable DAPs which the
National Computer Systems Laboratory (NCSL) plans to issue for Federal agency
use.
73
4.2 GRAPHICS
The graphics requirements for GOSIP include the Computer Graphics Metafile
(CGM). The purpose of CGM is to facilitate the transfer of picture
description information between different graphical software systems,
different graphical devices and different computer graphics installations.
CGM specifies a file format suitable for the description, storage and
communication of picture description information in a device-independent
manner.
Requirement
FIPS PUB 128 announces the adoption of the American National Standard for
Computer Graphics Metafile, ANSI X3.122-1986, as a Federal Information
Processing Standard (FIPS). This standard is intended for use in computer
graphics applications that are either developed or acquired for government
use. When computer graphics metafile systems for GOSIP are developed
internally, acquired as part of an ADP system procurement, acquired by
separate procurement, used under an ADP leasing arrangement, or specified for
use in contracts for programming services, they shall conform to FIPS PUB 128.
Status
A. Standards - Computer Graphics Metafile (CGM) ANSI X3.122-1985, ISO
8632/1-4-1987, FIPS
128-1987.
B. Application Profiles - MIL-D-28003 "Digital Representation of
Communication of Illustration Data: CGM Application Profile" 30 December 1988.
Plan
An Application Profile (AP) defines additional requirements beyond ANSI CGM to
ensure interoperability of implementations for specific applications.
Currently, two major application profiles exist for CGM; the TOP AP, and the
CALS AP (MIL-D-28003). As these APs and other APs which are applicable for
Federal agency use are promulgated, they will be incorporated into FIPS 128.
GOSIP will reference applicable APs for CGM which NCSL plans to issue for
Federal agency use.
4.3 STANDARD GENERALIZED MARKUP LANGUAGE (SGML) APPLICATION PROFILE
Description
The Standard Generalized Markup Language (SGML) standardizes the application
of the generic coding and generalized markup concepts. It provides a coherent
and unambiguous syntax for describing whatever a user chooses to identify
within a document. It is a metalanguage for describing the logical and
content structure of a document in a machine processable syntax. The Standard
Generalized Markup Language can be used for documents that are processed by
any text processing or word processing system. It will be particularly
74
applicable to:
o documents that are interchanged among systems with differing text
processing languages
o documents that are processed in more than one way, even when the
procedures use the same text processing language.
Requirement
FIPS PUB 152 announces the adoption of the International Standards
Organization Standard Generalized Markup Language (SGML), ISO 8879-1986, as a
Federal Information Processing Standard (FIPS). This standard is intended for
use in documents that are processed by any text processing systems that are
either developed or acquired for government use. When SGML text processing
systems for GOSIP are developed internally, acquired as part of an ADP system
procurement, acquired by separate procurement, used under an ADP leasing
arrangement, or specified for use in contracts for programming services, they
shall conform to FIPS PUB 152.
Status
A. Standards - Information Processing - Text and office systems -
Standard Generalized Markup Language (SGML), ISO 8879-1986 (E),FIPS 152-1988.
B. Application Profiles - MIL-M-28001A, "Markup Requirements and
Generic Style Specification for Electronic Printed Output and Exchange of
Text," December 1989.
MIL-M-28001A, "Markup Requirements and Generic Style Specifications for
Electronic Printed Output and Exchange of Text," established the requirements
for the digital data form of page oriented technical military publications.
Data prepared in conformance to these requirements will facilitate the
automated storage, retrieval, interchange, and processing of technical
documents from heterogeneous data sources. MIL-M-28001A requirements include:
o procedures and symbology for markup of unformatted text in accordance
with this specific application of the Standard Generalized Markup
Language;
o SGML compatible codes that will support encoding of a technical
publication to specific format requirements applicable to technical
manuals;
o output processing requirements that will format a conforming SGML source
file to the style and format requirements of the appropriate Formatting
Output Specification Instance (FOSI).
Plan
An Application Profile (AP) defines additional requirements beyond FIPS SGML
75
to ensure interoperability of implementation. MIL-M-28001 is an Application
Profile for technical military publications. The plan is to develop an SGML
Document Application Profile (SDAP) by extending MIL-M-28001 to be more useful
for generic documents and to incorporate the SDAP into FIPS 152. GOSIP will
reference applicable SDAPs which NCSL plans to issue for Federal agency use.
76
APPENDIX 5. LOWER LAYER PROTOCOLS
5.1 IS-IS DYNAMIC ROUTING PROTOCOLS
Within OSI networks, systems of routers (intermediate systems) enable the
effective and efficient interconnection of a diverse set of subnetwork types
(e.g., CSMA/CD, token ring, token bus, and X.25) into internetworks. Within
such an internetwork, messages are sent like postal letters from router to
router. At each router a message is examined and the next router is selected.
The effect of such a scheme is that each message may follow an independent
route. As conditions within the internetwork change (e.g., link, host, and
router failures and activations), the possibility exists for messages to reach
their destination despite failure of network elements. Such potential can
only be achieved if the system of routers exchanges information concerning the
state of routes. Protocols for exchanging information concerning varying
route conditions are known as dynamic routing protocols. Within OSI
standards, dynamic routing protocols are named intermediate system to
intermediate system (IS-IS) protocols.
Requirement
Dynamic routing is required within GOSIP to support the needs of several large
government internetworks. Two kinds of routing support are required: 1)
dynamic routing within an administrative domain, and 2) dynamic routing
between administrative domains. Routing requirements within an administrative
domain are well understood, and two generally acceptable schemes exist.
Routing requirements between administrative domains are not widely agreed
upon, although ECMA has produced a technical report.
Status
An intra-domain dynamic routing protocol was submitted to ISO from ASC X3S53.3
in January 1988. The submission is based on DEC's Phase V link state routing.
It was discussed at the November ISO SC6/WG2 meeting and was registered as a
DP in January 1990.
ECMA developed an inter-domain technical report (TR50), based on an NIST-
developed model. It was submitted by ECMA as a liaison to ISO WG2 in May 1989
as the proposed basis for an ISO inter-domain standard.
Plan
The NIST will support the progression of the DEC submission toward an ISO IS
through work in standards committees and laboratories. The NIST will also
prepare for establishing implementor agreements as the document reaches DIS.
The NIST will continue to support development of the inter-domain routing
protocol within ECMA, ANSI, and ISO.
The GOSIP will adopt intra-domain dynamic routing protocols as soon as
implementor agreements are in place. The projected date is 1991. The
adoption of an inter-domain routing protocol for GOSIP should occur one to two
77
years following adoption of an intra-domain protocol.
5.2 FIBER DISTRIBUTED DATA INTERFACE (FDDI)
FDDI is a 100 Mbit/s token ring network utilizing multimode fiber optic media.
Three standards, Physical Medium Dependent (PMD), Physical Layer Protocol
(PHY), and Medium Access Control (MAC) specify the Physical and Data Link
layers of the Open Systems Interconnection Reference Model. A fourth
standard, Station Management (SMT) interfaces to the first three layers to
control initialization and configuration of the ring, as well as
reconfiguration around faults, and will provide management services to higher
layer management protocols.
Requirement
MAC, PHY and PMD have a few options which require selection (e.g., 48 bit vs.
16 bit addressing) and a few timers and parameters which require further
definition (particularly of their default values) to ensure interoperability
in an OSI environment. One class of service (Restricted Token Mode) is
inappropriate in an OSI environment.
SMT is more complex, and will probably offer many options, particularly
regarding network policies, which will require some selection. In many cases,
this will simply mean selecting the default option or policy.
Status
A. Standards - The MAC (X3.139-1987) PHY (X3.148-1988) and PMD (X3.166-
1989) standards are approved. SMT is still under development and probably
will be forwarded in June 1990 and approved in 1991. Products implementing
FDDI are now widely available.
B. Implementors' Agreements - NIST has drafted an implementors'
agreement covering MAC, PHY and PMD. This was accepted into the ongoing
agreements by the Lower Level SIG and should be incorporated in Version 3.0 of
GOSIP. Although products are now starting to appear, SMT is not approved, but
is "stable", so work could begin on an implementors' agreement by mid-1990.
Plan
NIST will draft a proposed implementors' agreement covering SMT after SMT is
forwarded to approval, which will probably occur in June. The ANSI standard,
moreover, will not be completely stable until some time in 1990 or 199l, since
the public review usually results in changes. That means that closure on
implementors' agreements cannot be reached before some time in 1991 at the
earliest. This is not ideal, because there will be significant product
shipments in 1990.
Since SMT is largely software, vendors expect to update equipment already
shipped before SMT is finalized, by distributing new software (often on ROM
78
chips).
5.3 TRANSPORT PROTOCOL CLASS 2
The transport protocol, class 2, for use over the connection-oriented network
service (CONS) is accepted by several OSI profiles (e.g., UK GOSIP). The
transport protocol, class 2, is also used with CONS in several U.S. Government
applications, where communication is confined to a single logical subnetwork.
Requirement
The transport protocol, class 2, is desired in GOSIP as an optional transport
protocol for use with CONS, where communication is confined to a single
logical subnetwork. The transport protocol, class 4, operating over the
connectionless network service (CLNS), will remain the sole mandatory data
transport service for purposes of interoperability among U. S. GOSIP-compliant
computer systems. The specification of the transport protocol, class 2, as an
option in GOSIP, is intended to enable interoperability among U.S. Government
computer systems, when using class 2 transport over CONS. Such specifications
would be intended to prevent the spread of non-interoperable class 2 transport
implementations within the U. S. Government. The ability to choose the
correct transport protocol class for a given instance of communication will
require a prior knowledge on the part of the transport connection initiator,
until directory services are included in GOSIP.
Status
Although a few U.S. vendors provide implementations of the class 2 transport
protocol, the overwhelming majority offer class 4 transport only. The
Workshop Agreements endorse class 4 transport for use over
CLNS and CONS, and class 0 transport for use over CONS when direct access to
public messaging systems is required.
Plan
Interested government agencies brought the requirement for class 2 transport
implementation agreements to the attention of the Lower Layer SIG of the
NIST/OSI Implementors' Workshop. Workshop Agreements are now in place, so
consideration canbe given to inclusion of an optional class 2 transport
capability into GOSIP, Version 3.0.
5.4 INTEGRATED SERVICES DIGITAL NETWORK
Integrated Services Digital Networks (ISDN), supporting integrated voice,
data, image, and video are expected to be deployed on a wide scale in
ubiquitous public offerings and in private network offerings, as services and
as components from which private ISDN networks can be constructed. Initial
offerings will be a switched 64 kbps service delivered to a customer's
terminal at a basic rate (16 Kbps signaling channel and two 64 KBPS data
channels) or a primary rate (24 64 Kbps channels, one used for signalling).
Later offerings, now in the development phases, will offer higher capacities,
79
estimated at 150 Mbps to 622 Mbps.
Requirement
One use for ISDN is to provide a bearer service for OSI data protocols; thus,
ISDN is included in GOSIP as a lower layer service. Other ISDN applications
include integrated voice, image, data, and video, and, therefore, non-GOSIP
ISDN applications can be expected. NIST plans to issue a variety of FIPS that
enable the government to exploit the full technical capabilities of ISDN. The
initial focus aims at switched 64 Kbps service for voice, voice/data, and, in
GOSIP, OSI data. Both the basic and primary rates are needed. Later
broadband ISDN (B-ISDN) is needed. The initial fundamental requirements are:
1) specifications enabling multi-vendor interconnection compatibility between
terminal equipment and switching equipment and 2) specifications enabling
multi-vendor interconnection compatibility between switching equipment.
Status
The North American ISDN Users Forum (NIU-FORUM), comprising a user's workshop
(IUW) and an implementor's workshop (IIW), is addressing issues of multi-
vendor terminal equipment-to-switch and switch-to-switch interoperation and
ISDN application profiles. Some implementation agreements and application
profiles are expected by the end of 1990.
Plan
The GOSIP FIPS will reference appropriate IIW agreements and ISDN FIPS as they
become available. NIST plans to issue ISDN FIPS for integrated voice, image,
data, and video and non-OSI data, as appropriate agreements are achieved in
the IIW and IUW. The primary requirement for ISDN in GOSIP is as a network
bearer service accessible via terminal equipment and switching equipment that
can be connected readily, regardless of the specific vendor. The GOSIP FIPS
will evolve to account for availability of B-ISDN and the Synchronized Optical
Network (SONET).
80
APPENDIX 6. ACRONYMS
ACSE Association Control Service Element
AE Application Entity
AFI Authority and Format Identifier
ANSI American National Standards Institute
AP Application Profile
ASCII American Standard Code for Information Interchange
ASN Abstract Syntax Notation
BRI Basic Rate Interface
CCITT Consultative Committee for International Telegraph & Telephone
CGM Computer Graphics Metafile
CLNP Connectionless Network Protocol
CLNS Connectionless Network Service
CLTP Connectionless Transport Protocol
CLTS Connectionless Transport Service
CMIP Common Management Information Protocol
CMIS Common Management Information Services
CONS Connection-Oriented Network Service
COTS Connection-Oriented Transport Service
CSMA/CD Carrier Sense, Multiple Access with Collision Detection
DAP Document Application Profile
DIS Draft International Standard
DOD Department of Defense
DOE Department of Energy
DP Draft Proposal
DSP Domain Specific Part
DTR Draft Technical Report
ECMA European Computer Manufacturers Association
EIA Electronic Industries Association
ES-IS End System-Intermediate System
FADU File Access Data Unit
FAR Federal Acquisition Regulation
FDDI Fiber Distributed Data Interface
FIB Forwarding Information Base
FIPS Federal Information Processing Standard
FIRMR Federal Information Resources Management Regulation
FTAM File Transfer, Access, and Management
GENSER General Service
GOSIP Government Open Systems Interconnection Profile
GSA General Services Administration
HDLC High Level Data Link Control
ICD International Code Designator
IDI Initial Domain Identifier
IDP Initial Domain Part
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronic Engineers
IRV International Reference Version
IS International Standard
IS Intermediate System
IS-IS Intermediate System-Intermediate System
81
ISDN Integrated Services Digital Network
ISO International Organization for Standardization
JTC Joint Technical Committee
LAN Local Area Network
LAPB Link Access Procedure B
LAPD Link Access Procedure D
MAC Medium Access Control
MAP Manufacturing Automation Protocol
MHS Message Handling Systems
MMS Manufacturing Message Specification
NCS National Communications System
NIST National Institute of Standards and Technology
NMSIG Network Management Special Interest Group
NPDU Network Protocol Data Unit
NPAI Network Protocol Access Information
NSA National Security Agency
NSAP Network Service Access Point
ODA Office Document Architecture
OSIO Open Systems Interconnection
PCI Protocol Control Information
PDN Public Data Network
PDU Protocol Data Unit
PHY Physical Layer Protocol
PLP Packet Level Protocol
PMD Physical Medium Dependent
PRI Primary Rate Interface
PSAP Presentation Service Access Point
RDA Remote Database Access
RFP Request For Proposal
RIB Routing Information Base
SAP Service Access Point
SC Steering Committee
SCI Special Compartmented Information
SDNS Secure Data Network Service
SGML Standard Generalized Markup Language
SIG Special Interest Group
SILS Standard for Interoperable LAN Security
SIOP-ESI Single Integrated Operational Plan-Extremely Sensitive Info.
SMT Station Management
SNPA Subnetwork Point of Attachment
SQL Structured Query Language
SSAP Session Service Access Point
SVC Switched Virtual Circuit
TC Technical Committee
TOP Technical and Office Protocols
TP Transaction Processing
TSAP Transport Service Access Point
TTY Teletype
VT Virtual Terminal
WAN Wide Area Network
WG Working Group
WYSIWYG What You See Is What You Get
82
83
